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ABSTRACT 


The Adaptive Architectures for Command and Control (A2C2) project is a 
four-year effort sponsored by the Office of Naval Research to explore adaptation in 
command and control structures. The project’s first experiment involves studying 
interaction between task structure and organization structure. Although the organization 
structure dimension of interest was clear, not enough was known of the dimensions of 
task structure to determine the dimension of interest without further study. This thesis 
describes a process for developing military operational scenarios within a task structure 
context. First, the author conducts a literature review, defines the dimensions of task 
structure applicable to this project, develops a grading scale for each dimension, gives 
examples of the dimensions and grades each example, and describes how changes in one 
dimension might affect other dimensions. Then a method for developing scenarios in 
accordance with a predetermined structure and visualizing tasks is described, including a 
task structure diagram and a description of a task design process using the diagram and 
the dimensions previously delineated. The author then applies the task design process by 
developing two scenarios for the first A2C2 experiment that differ across one dimension 
of task structure, coordination requirements. Finally, a description of the experiment is 
given, including discussion of operationalization of the scenarios and organization 
structures, and lessons learned from the experiment with regard to scenario design. 
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EXECUTIVE SUMMARY 


The Adaptive Architectures for Command and Control (A2C2) project is a 
four-year effort, sponsored by the Office of Naval Research and conducted by researchers 
at the Naval Postgraduate School (NPS), Alphatech, Inc., the University of Connecticut, 
and several other institutions. The goal of the study is to explore how, why, and when 
organizations adapt or should adapt their structures and what skills, training, and 
technology are required to support that adaptation. The project itself will consist of field 
research and a series of experiments. 

The first experiment was conducted at NPS in March 1996. The purpose of this 
initial experiment is to serve as a “baseline” for the experimental phase of the A2C2 
project, and to study interaction between task structure and organization structure, in a 
2x2 factorial experimental design. The organizational structure dimension of interest was 
clear from the overarching purpose of the A2C2 project and current emphasis in the 
Department of Defense and industry on “flattening” organizational structures: levels of 
hierarchy — does a flattened hierarchy perform tasks better under certain circumstances 
than a hierarchy with more levels? However, the task structure dimension of interest was 
less clear. Although there are several discussions in the literature of single dimensions of 
task structure, nowhere is there a comprehensive breakdown of the dimensions of task 
structure, including sonie way of quantifying or determining the levels of each of those 
dimensions so they can be held constant or varied in a situation where task structure is an 
independent variable. And, once these dimensions are defined and the dimension to be 
varied has been decided upon, how can a task be visually represented for ease of 
understanding and manipulation, and a military operational scenario be designed to fit 
into this task structure? This task design and scenario development process is the focus 
of this thesis. 

The author begins by conducting a literature review, and defines the dimensions of 
task structure applicable to this project based on the literature and his own experience. 
These dimensions are uncertainty, time pressure, complexity, coordination requirements. 
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magnitude, resources required, information required, task formalization, and dynamicity. 
Then, a grading scale for each dimension is developed, examples of the dimensions are 
given and graded based on the previously developed scale, and the author describes how 
changes in one dimension might affect other dimensions. 

Once the dimensions of task structure are defined and a grading scale developed, 
the author describes a task structure diagram, whose purpose is to visually represent the 
flow of activities within a task, possible paths, simultaneity constraints, competition over 
resources, prerequisites for activities, resources and information required for the 
performance of activities, decomposability of activities, and dynamicity, or the degree to 
which activities change over time, to experimental designers. Many of the dimensions of 
task structure previously described are represented directly in this diagram; others can be 
inferred from it. This visual method allows experimenters to more easily determine if a 
task accomplishes the objectives that have been set, and provides a straightforward, visual 
method for comparing it with other tasks and for describing a task to those outside the 
task design process. After the diagram has been developed, the author describes how the 
dimensions of task structure defined previously relate to the visual method. Then, the 
author describes a straightforward process for developing military operational scenarios 
when task structure is to be an independent variable. The steps in the process are to 
determine the task structure dimension of interest, determine desired task structure and 
levels of dimensions, develop the scenario, and grade the scenarios by dimensions. 

The author then applies the task design process described above to the A2C2 initial 
experiment. The dimension of interest was determined by the definitions of dimensions of 
task structure given previously and initial A2C2 field research, where the question was 
repeatedly asked: when two units in the same ftmctional area must compete over assets 
owned by one of them, does an intermediate level of hierarchy overseeing that functional 
area help, or is a flattened hierarchy better? And which organizational structure is better 
if the units are competing over assets owned outside their functional area? The 
dimension of interest, then, is coordination requirements, at two levels: high internal 
competition over shared resources and high external competition over shared resources. 
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The author begins with the scenario used for A2C2 field research and develops two 
scenarios at the joint task force (JTF) level that differ across the dimension of interest, 
and grades the scenarios based on the dimensions of task structure developed previously. 

Finally, the author gives a description of the experiment, including setup, 
discussion of operationalization of the scenarios and organization structures, training 
conducted with the subjects, conduct of the experiment itself, and lessons learned from 
the experiment with regard to scenario design, in terms of the usefulness of the scenario 
design process described in this thesis and issues that must be taken into account in order 
to effectively design and implement a scenario that contains independent variables. 
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I. INTRODUCTION 


A. BACKGROUND 

In the effort to capitalize on the ongoing revolution in military affairs, a current 
area of focus within the Department of Defense is organization of the force. New, more 
highly evolved organizational concepts are considered one of the “enablers of the 
revolution in military affairs” (Joint Warfighting Center, 1995, p. 13). The Joint Staffs 
C4I for the Warrior (C4IFTW) concept, Copernicus, Sea Dragon, and other service 
initiatives that reside within the overarching C4IFTW concept call for flattened command 
structures. These flattened command structures would make more efficient use of 
enhanced sensor-to-shooter communications capabilities and the dominant battlespace 
knowledge that, it is hoped, U.S. forces are on the road to achieving as a result of the 
tremendous pace of technological advance and our leveraging of that technology. Further, 
it is posited that the most responsive and capable organizations will adapt their structures 
and processes from traditional, rigid hierarchical organizational structures into more 
flexible, network-like architectures in order to take advantage of the opportunities 
presented by the information age (Joint Warfighting Center, 1995, p. 18). 

B. THE A2C2 PROJECT 

It was within this context that, in the summer of 1995, the Office of Naval 
Research (ONR) commissioned a four-year research project called Adaptive 
Architectures for Command and Control (A2C2). The A2C2 project is a joint effort of 
researchers at the Naval Postgraduate School (NPS), Alphatech, Inc., the University of 
Connecticut, and several other academic institutions. The project’s goal is to advance the 
state of knowledge regarding decision making in organizational settings, to include an 
understanding of how, why, and when organizations adapt or should adapt and what 
skills, training, and technology are required to support that adaptation 
(Alphatech/UCONN/NPS, 1995, p. 2). The researchers will make use of theory, practical 
experiments, and field observation in order to gain this understanding. The A2C2 project 
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will move through several different phases, which began in late 1995 with visits to 
military organizations, participation in demonstrations and wargames, and a round of 
structured interviews with experienced commanders from all branches of the U.S. Armed 
Forces. The purpose of this field research was to identify drivers of adaptation in joint 
operations, from the perspective of those experienced in joint operations, and raise the 
specific issues that can and should be dealt with in the project’s later experiments. 

After the interviews, the A2C2 researchers have begun to conduct a series of 
experiments of gradually increasing complexity and fidelity. Each experiment will build 
upon the insights gained from modeling, the field research, and previous experiments, 
and will be conducted using wargame/simulators of complexity and fidelity 
commensurate with the experiment being conducted. This thesis involves the first of 
those experiments, which was conducted using the Distributed Dynamic Decisionmaking 
III (DDD-III) simulator, a relatively low-fidelity, high-abstraction tool, with officer 
students from NFS representing each branch of the service as subjects. 

C. THE FIRST A2C2 EXPERIMENT 

The first experiment in the A2C2 project was conducted at NFS in March 1996. 
The purpose of this initial experiment was to serve as a “baseline” for the experimental 
phase of the A2C2 project. Objectives included: adapting the existing game simulator 
(DDD III) to the broader operational domain; examining organizational structure as an 
independent variable, and testing interaction between organizational structure and task 
structure; identifying current research issue(s) that are common to the operational and 
theoretical (from literature) domains, that can be examined within the context of the 
scenario used in the interviews; developing the scenario and tasks down to a level 
amenable to modeling analytically and in simulation; providing insight into 
wargame/simulator requirements for future experiments; and examining measures that 
may be useful for research into adaptable C2 architectures. 

The first experiment was conducted at the intersection of a number of constraints. 
These included the field research that had been conducted, to include the joint officer 
interviews and field visits to exercises and warfighting commands; the pool of 
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experiment subjects at NPS; the requirement that any scenario developed be joint in its 
nature; the hardware available to conduct the experiment at NPS; the factors of interest to 
the A2C2 project; the requirement that the experiment be conducive to modeling and 
simulation; and the capabilities and limitations of DDD III. 

Testing the organizational structure/task structure interaction was the driver of the 
experimental design. When testing this interaction, in order to isolate effects, it was 
desired that task structure and organizational structure be varied in only one dimension 
each, holding all others constant. This resulted in a 2^ factorial design, with each factor 
held at two levels. The A2C2 team decided to use four six-person teams, composed of 
military officers from all four services with normally one or two operational tours behind 
them, conducting four trials per team in a balanced, full-factorial design with four data 
points in each task/organization structure combination. 

The difficult question, then, is which dimensions of organizational structure and 
task structure should be varied? And, once that is decided, at what two levels should the 
dimensions be held? The overarching purpose of the A2C2 project and the current issues 
being addressed in Copernicus and C4IFTW suggested clearly that, in the case of 
organizational structure, the dimension of interest should be levels of hierarc^: is 
performance of an organization enhanced if one or more levels of hierarchy is removed 
(the “flattened” structure envisioned as superior in the technology-enhanced near future), 
particularly in an environment where there exists a common operational picture (COP) 
among all members of an organizational structure? The A2C2 team further decided that 
the two levels to be tested should be a two-tiered hierarchy and a three-tiered hierarchy 
(Figure 1). Task structure, though, was more difficult. While the literature on the subject 
of organizational structure is rich, plentiful, and well-developed, that regarding task 
structure is not. Although there are several discussions in the literature of single 
dimensions of task structure, such as complexity, uncertainty, or coordination 
requirements, nowhere is there a comprehensive breakdown of the dimensions of task 
structure, including some way of quantifying or determining the levels of each of those 
dimensions so they can be held constant or varied in a situation where task structure is an 
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independent variable. And, once the dimensions of task structure are defined, the 
dimension to be varied has been decided upon, and the structural form which the task will 
take has been determined, how can a military operational scenario be built to fit into this 
task structure? This task design and scenario development process is the focus of the 
thesis. 


Organization Structures 

CJTF 

MCC 

ARG CVBG 

CJTF 

ARG CVBG 


Figure 1. Two Organization Structures Used for First Experiment 

D. FOCUS OF THESIS 

The purpose of this thesis is to develop a process for developing military 
operational scenarios within a task structure context. As a starting point, I will perform a 
comprehensive literature review, define the dimensions of task structure, quantify those 
dimensions, and give examples of each dimension and quantifications of the examples 
(Chapter II). I will then develop a diagram to be used for developing scenarios in 
accordance with a predetermined structure, and correlate the dimensions of task structure 
that I define in Chapter II with the elements of the task structure diagram, and briefly 
outline a task design process based on the dimensions from Chapter II and the task 
structure diagram (Chapter III). I will subsequently develop two joint tactical scenarios 
written for the DDD simulator that differ across the dimension of task structure that the 
A2C2 experimental team decides is the most important one, and in conjunction with the 
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predetermined structure that the A2C2 team decides that it wants to use, utilizing the task 
design process from Chapter III. The results, analysis, and conclusions of the first A2C2 
experiment are outside the scope of this thesis. However, I will describe the conduct of 
the experiment and operationalization of the scenarios and organization structures 
(Chapter IV). Finally, I will detail lessons learned fi'om the experiment and application of 
the task design process as they pertain to scenario development and task design, and I will 
summarize the thesis (Chapter V). 
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11. DEFINING DIMENSIONS OF TASK STRUCTURE 


A. INTRODUCTION 

It is clear that, in order to successfully determine which types of organizations 
function best with different sorts of tasks, an organized and disciplined method with 
which to cause tasks to be different must exist. In order to cause tasks to be different, we 
must be able to differentiate between tasks. And, before we can differentiate between 
tasks, a task must be characterized. One way to characterize tasks is to decompose each 
task by the level of its various dimensions. What, though, are those dimensions of task 
structure? As mentioned in the previous chapter, there is little in the literature of 
organization theory and behavioral decision theory with regard to dimensions of task 
structure. Discussions of one or several dimensions of task structure are common (Wood, 
1986, Campbell, 1988, Malone and Crowston, 1994, Ben Zur and Breznitz, 1981, Davis 
et al., 1991, Evaristo et al., 1995), but a comprehensive enumeration of these dimensions 
is lacking. 

The purpose of this chapter is, first, to review the literature on the subject of task 
structure. Next, I will enumerate and define dimensions of task structure, based partly on 
the literature and partly on my professional experience, and develop a grading scale for 
each dimension. I will then give examples of tasks that clearly exhibit the dimension of 
interest, and grade each example given using the seale developed earlier. Finally, I will 
discuss the interaction between dimensions or the degree to which changing one 
dimension affects other dimensions. 

B. LITERATURE REVIEW 

The literature on dimensions of task structure is mainly composed of articles and 
papers from technical journals. The works described below are the most significant to 
date from the perspective of enumerating dimensions of task structure. Six articles are 
discussed: Wood (1986) and Campbell (1988) deal with complexity, Malone and 
Crowston (1994) consider eoordination requirements, Ben Zur and Breznitz (1981) deal 
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with time pressure, Evaristo et al. (1995) describe time pressure and uncertainty, 
and Davis et al. (1991) discuss task activities, time frame, task formalization, task 
ambiguity, task complexity (using Wood’s (1986) definition), and task significance. 

1. Wood 

Robert E. Wood, in his article, “Task Complexity: Definition of the Construct” 
(1986), first states that tasks contain three components: (1) the product, or what is 
produced by completing the task; (2) acts, or things that must be done in order to 
complete the task; and (3) information cues, or information that provides the stimulus for 
performance of a task, or is required for the task to be completed. He then defines task 
complexity in terms of these three task components, and decomposes task complexity 
into three different components: component complexity, coordinative complexity, and 
dynamic complexity, and discusses methods for quantifying each of the components. 

a. Component Complexity 

Component complexity is a direct function of the number of distinct acts 
that must be completed in the performance of the task and the number of distinct 
information cues that must be processed in order to perform the acts. Wood gives the sum 
TC„ the measure of component complexity, as the sum of information cues for all acts of 
all subtasks within the task. 

b. Coordinative Complexity 

Coordinative complexity, as defined by Wood, refers to the relationships 
between task inputs and task products. It describes the form and strength of the 
relationships between information cues, acts, and products, as well as the sequencing of 
inputs. Wood gives a number of different indices with which to attempt to measure 
coordinative complexity, most of which are a bit obscure and difficult to obtain, and I 
will not elaborate on them because of the space that would require. The most 
straightforward is the sum of all precedence relations between each act and all other acts 
in the task, which he denotes TCj. 
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c. Dynamic Complexity 

Wood defines dynamic complexity as changes in the task environment 
which affect the relationships between task inputs and products. He measures this by 
summing the changes in TC, and TCj over discrete time periods, reduced by the change 
multiplied by a predictability coefficient for each time period, to arrive at a dynamic 
complexity figure denoted TC3. 

d. Total Complexity 

To arrive at a figure for total complexity. Wood obtains a weighted sum of 
the TC,, TCj, and TC3 totals. The specific weights, represented by coefficients, assigned 
to each sum would be situationally dependent, constrained by the requirement that TC, be 
more heavily weighted than TC2, and TC2 more heavily weighted than TC3. 

2. Campbell 

Donald J. Campbell, in his article “Task Complexity: A Review and Analysis” 
(1988), took a different approach to defining complexity. He posited that task complexity 
is closely related to information, and that any task attributes that increase the load, 
diversity, or rate of change of information should be considered contributors to task 
complexity. He found four task characteristics that meet that criterion: the degree to 
which a task contains multiple paths, multiple outcomes, conflicting interdependence 
among paths, and uncertain or probabilistic linkages. 

a. Multiple Paths 

Increasing the number of possible ways to complete a given task increases 
the complexity of the task. This is particularly true if the paths vary in their “goodness,” 
that is, some paths more efficiently or effectively complete the task than others. 
Complexity is reduced if all paths presented are of equal goodness. 
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b. Multiple Outcomes 

Outcomes are the different results the performer of the task wants to 
achieve when the task is completed. The greater the number of different outcomes, the 
more complex the task. 

c. Conflicting Interdependence Among Paths 

Campbell defines this as negative relationships among desired outcomes. 
If achieving one outcome conflicts with achieving another outcome, task complexity 
increases. 


d. Uncertain or Probabilistic Linkages 

Campbell defines linkages as the connection between potential path 
activities and desired task outcomes. If there is difficulty determining these linkages, or 
the linkages have a probability of less than one, information processing requirements are 
increased significantly, and task complexity increases. 

3. Malone and Crowston 

Thomas W. Malone and Kevin Crowston, in their paper “The Interdisciplinary 
Study of Coordination” (1994) define coordination as managing dependencies between 
activities. They defined four different types of dependencies that could need to be 
managed: shared resources, producer/consumer relationships, simultaneity constraints, 
and task/subtask relationships. 

a. Managing Shared Resources 

Whenever more than one actor or activity requires a limited resource, 
coordination is required to ensure that the resource is properly allocated among the actors 
or activities. 


b. Managing Producer/Consumer Relationships 

A producer/consumer relationship is one in which one actor or activity 
produces something that is used by another actor or activity. 
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c. Managing Simultaneity Constraints 

Simultaneity constraints occur where more than one activity must be 
performed at the same time as another, or when one activity must be performed at a 
specific time in relation to the performance of another activity. 

d. Managing Task/Subtask Relationships 

Task/subtask relationships occur when a task must be broken up into 
multiple subtasks, and the subtasks divided up among multiple actors or different time 
periods for completion. 

4. Davis, Collins, Eierman, and Nance 

Gordon Davis, Rosann Webb Collins, Michael Eierman, and William Nance, in 
their working paper “Conceptual Model for Research on Knowledge Work” (1991) 
discuss characteristics of task environment that apply to knowledge tasks rather than 
manual tasks. They came the closest, of any work with which 1 am familiar, of attempting 
to somewhat comprehensively enumerate dimensions of task structure, although I do not 
believe that their enumeration is complete, or that they even, in some cases, considered 
the right dimensions. However, some of the characteristics they describe are quite useful. 
They discuss six characteristics: task activities, time frame, task formalization, task 
ambiguity, task complexity, and task significance, of which formalization, ambiguity, and 
complexity are the most suitable for the purposes of this thesis. 

a. Task Activities 

Davis et al. define task activities as the operations that must be 
implemented to complete a task, with each activity being associated with one or more 
problem spaces. 

b. Time Frame 

The amount of time it will take to complete a task. 
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c. Task Formalization 

The authors consider task formalization to be the level of specification and 
structure that is imposed on the performance of the task, or task inputs or outputs. A task 
with high formalization would be described in a very structured way; there are certain 
well-defined activities that must be performed in a explicit order to complete the task. In 
a task with low formalization, though, the activities required to complete the task, and 
even the goals of the task, would be poorly defined and open to interpretation. 

d. Task Ambiguity 

Task ambiguity is defined as the clarity of understanding of the activities 
that are required to complete a task, or of the inputs or outputs of a task. 

e. Task Complexity 

The authors use Wood’s (1986) definition of complexity. 

f. Task Significance 

Task significance is defined as the value of the task output to the 
organization performing the task, and the interdependency between task outputs and other 
operations of the organization. 

5. Evaristo, Adams, and Curley 

Roberto Evaristo, Carl Adams, and Shawn Curley, in their article “Information 
Load Revisited: A Theoretical Model” (1995) describe three task characteristics: time 
pressure, task formalization, and task complexity. The authors define time pressure as the 
time available to perform the task, and reiterate Davis et al.’s (1991) definition of task 
formalization and Wood’s (1986) definition of task complexity. Their most interesting 
contribution is their description of uncertainty, although they do not consider it a task 
characteristic, but an information characteristic. They define uncertainty as knowledge 
inadequacy, resulting in an actor’s inability to predict something accurately. They fiuther 
cite the sources of uncertainty as unavailability or incompleteness of information, low 
information reliability, and information novelty. 
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6 . 


Ben Zur and Breznitz 


Hasida Ben Zur and Shlomo J. Breznitz, in their article “The Effect of Time 
Pressure on Risky Choice Behavior” (1981) define time pressure as the amount of 
information that must be considered and processed during one time imit, or as the time 
allotted for processing a fixed amount of information. Their definition refers to time 
pressure in the information domain, but it could be generalized to include the task domain 
as well. 

C. ENUMERATION OF DIMENSIONS OF TASK STRUCTURE 

The dimensions of task structure are the concepts by which a task can be 
described. Below is an attempt to comprehensively define the dimensions of task 
structure that are of interest in experimentation, particularly within the A2C2 context. 
Nine dimensions are detailed: uncertainty, time pressure, complexity, coordination 
requirements, magnitude, resources required, information required, task formalization, 
and dynamicity. These dimensions would ideally be orthogonal, but if complete 
orthogonality is possible, it would certainly have come at a price in comprehensiveness 
that I was not willing to pay. Thus, there is some interaction between dimensions (which 
will be discussed in the section following), although I believe it is minimized. For each 
dimension of task structure, I give a definition and an example in a military operational 
context, and then describe how any given task could be graded in that dimension by 
establishing levels at which the dimension could be measured. I then grade the example 
given with the definition. 

1. Uncertainty 

a. Definition 

Uncertainty is defined as the degree to which information about states, 
inputs, outcomes, or environments of tasks is unknown (Evaristo, et al., p. 200). 


13 


b. 


Levels 


This dimension is difficult to quantify, and grading must be done on a 
subjective basis. There are a number of ways to subjectively grade dimensions, which 
will be used throughout this chapter. First, anchored scales can be used. Anchored scales 
are scales of measurement (from 0 to 100, for example) in which illustrations are given of 
a task that would be graded (“anchored”) at various points on the scale, typically the high 
and the low ends. For example, if “uncertainty” was graded using an anchored scale, an 
event of which absolutely no information about states, inputs, outcomes, or environments 
was known would be considered a “0,” and an event about which all information about 
states, inputs, outcomes, or environments was known would be considered a “100.” The 
benefit of an anchored scale is that it allows for a moderate amount of transportability, 
that is, tasks that are not necessarily being evaluated in terms of one another and are 
otherwise dissimilar can be compared using a well-anchored scale. Another option for 
subjectively grading dimensions is to use a scale such as High, Medium, Low, and None. 
This scale would be adequate in circumstances where the only comparison of tasks that is 
of interest is between two or more tasks that are generally being evaluated in terms of one 
another, and are otherwise similar. Grading using this scale is rather arbitrary, depending 
on the grader’s definition of the level, so its transportability is low. 

c. Example 

A simple example of uncertainty would involve an AW ACS operator 
dealing with unknown air tracks. Since the identification and intentions of the aircraft are 
not known (incomplete information on states, inputs, and environments), the AWACS 
operator is unsure whether to direct that the aircraft be shot down, warn it away, or let it 
continue what it is doing (incomplete information on outcomes). This task would be 
graded as Medium or High uncertainty. 
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2 . 


Time Pressure 


a. Definition 

Time pressure is the amount of activity that must be completed within a 
given amount of time (Ben Zur and Breznitz, 1981, p. 89). Alternately, it could be 
defined as the degree to which an individual or group performing a task are stressed by 
the requirement to complete the task within a given amount of time. I chose time pressure 
as a dimension rather than Davis et al.’s (1991) task characteristic “time frame,” because 
time frame does not take into account the magnitude of the task at hand, while time 
pressure, being measured as a rate, does. 

b. Levels 

Time pressure could be either represented using a subjective scale, such as 
High, Medium, Low, or None, or an anchored scale, or a more objective, quantitative 
scale, depending on the variation of the above definition that is being used. A subjective 
scale would suggest itself if comparing two or more dissimilar tasks, and the only 
information the researcher is interested in is whether there is time pressure on the task 
performer to complete the task within a certain period of time, and what the relative 
levels between the two or more tasks are. A quantitative scale would suggest itself when 
comparing tasks which are similar in most dimensions. Time pressure could then be 
represented as the number of activities or subtasks that must be completed, divided by the 
time available to complete the task. This method, unfortunately, requires a standard 
definition of activity or subtask, both in magnitude and duration. If two tasks are equal in 
the quantitative measure of time pressure described above, but one task’s subtasks or 
activities take significantly longer to perform than the other task’s, then the quantitative 
scale is inappropriate. In situations where the grader cannot with confidence equate the 
subtasks or activities of one task with those of another, time pressure should be graded 
using the subjective scale. 
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c. Example 

An example of time pressure from the Persian Gulf conflict is a mobile 
SCUD missile launcher, spotted setting up and preparing to fire. The identification 
information must be passed from the sensor to a control agency with the assets on hand to 
destroy the launcher, an asset must be assigned to destroy the launcher, the asset must 
travel to the launcher, and the asset must destroy the launcher, all in a matter of a few 
minutes*. This task has High time pressure, on a subjective scale. On an objective scale, if 
identifying, passing information, assigning an asset, getting in position to attack, and 
attacking are all considered subtasks, and the time available is 10 minutes, then time 
pressure is 5/10 or 0.5 subtasks per minute. 

3. Complexity 

I chose a variation on Campbell’s (1988) definition of complexity over Wood’s 
(1986), for several reasons. First, Campbell’s four characteristics of complexity are more 
easily understood than Wood’s three components of complexity, and are more simply 
measurable. Second, Wood’s description of coordinative complexity is very close to 
Malone and Crowston’s (1994) definition of coordination, which I chose to include as a 
separate dimension listed in paragraph four below. Finally, Wood’s concept of dynamic 
complexity is generalizable to all dimensions of task structure, not just complexity, and it 
is included as dynamicity, in paragraph nine below. 

Complexity, then, can be defined as the degree to which a task contains five task 
characteristics; multiple attributes, multiple paths, multiple outcomes, conflicting 
interdependence among outcomes, and uncertain or probabilistic linkages (Campbell, 
1988, p. 43). Multiple attributes has been added to Campbell’s original list of four 
characteristics on the basis of other articles. Specific definitions of the five task 
characteristics are as follows: 


’This was rarely, if ever, successfully done during the Persian Gulf conflict. 
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Multiple Attributes 


a. 


(1) Definition. The number of attributes that a task performer 
must take into account, or more than one thing that must be taken into consideration in 
order to complete the task, directly affect task complexity. The more attributes a task has, 
the more complex it is. 

(2) Levels. Multiple attributes is graded by the number of 
attributes that must be taken into consideration. 

b. Multiple Paths 

(1) Definition. The number of paths that could be taken to arrive 
at a desired outcome (Campbell, 1988, p. 43). 

(2) Levels. This aspect of complexity is graded by the 
approximate number of paths that could be taken to arrive at the desired endstate. In 
many cases, this ntunber could be infinite, or approach infinity. When this is true, the 
evaluator should only count the major variations of paths. 

c. Multiple Outcomes 

(1) Definition. The number of outcomes desired from a task. 

These outcomes need not be mutually exclusive (Campbell, 1988, p. 43). • 

(2) Levels. This aspect is graded by the number of different 
outcomes that the task performer needs to achieve. 

d. Conflicting Interdependence Among Outcomes 

(1) Definition. Conflicting interdependence among outcomes is a 
negative relationship between desired outcomes. If achieving one desired outcome 
conflicts with achieving another desired outcome, complexity increases (Campbell, 1988, 
P- 44). 
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(2) Levels. Conflicting interdependence among outcomes can be 
graded by counting the number of conflicts between instances of subparagraph (c) above. 
Each conflict should then be given a grade of 1 if the conflict is minor, 2 if it is moderate, 
and 3 if it is severe, or some similar scale. These grades should then be totaled across all 
conflicts so that each task has a single, numerical grade. 

e. Uncertain or Probabilistic Linkages 

(1) Definition. The condition where the connection between the 
potential path activities and the desired outcomes from a task are uncertain, or 
probabilistic (Campbell, 1988, p. 45). 

(2) Levels. High, Medium, Low, or None. 

f. Example 

A good general example of complexity is the conduct of an amphibious 
assault. The amphibious assault task contains multiple attributes (terrain, hydrography, 
enemy positions, roads, beaches, enemy reinforcement capability, etc.) One desired 
outcome of the task is to destroy or suppress enemy positions at or near the beachhead. 
There are several ways to do this (multiple paths), such as to use close air support, naval 
gunfire, infiltrate SEAL or reconnaissance teams, or some combination. There are also 
many additional outcomes (multiple outcomes) that are desired, such as to achieve 
surprise and minimize casualties. However, achieving surprise and destroying and 
suppressing enemy positions are usually mutually exclusive (conflicting interdependence 
among paths) — if the commander precedes his amphibious assault with a heavy air and 
sea bombardment, he will stand a good ehance of destroying or suppressing the enemy 
positions, but he will probably destroy the element of surprise. Finally, if the enemy’s 
positions at or near the beach are well protected and disguised, the commander is 
uncertain whether his possible actions of close air support, naval surface fire support, etc. 
will be able to successfully aehieve his desired outcome of suppressing or destroying the 
enemy positions (uncertain or probabilistic linkages). 
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This example would be graded as follows; 


(1) Multiple Attributes: The task attributes that must be 
considered in an amphibious assault are objective, time available, terrain, weather, 
hydrography, friendly forces available, enemy positions, enemy reinforcements, enemy 
air threat, enemy sea threat, enemy anti-air threat, beaches, mobility on land, and 
non-combatants, for a total of 14. These are very high-level attributes, so it would be 
inappropriate to compare this task with a task in which the attributes were low-level. 

(2) Multiple Paths: The number of paths that could be taken to 
conduct an amphibious assault is infinite. They can be categorized into major variations, 
however. The major paths that could be taken are to conduct the assault (as an 
across-the-beach assault, vertical envelopment, or combination) with extensive air and 
naval surface fire support beaeh preparation, conduct the assault without extensive air and 
naval surface fire support beach preparation, conduct the assault while 
destroying/suppressing enemy positions using stealthy means (SEAL/Recon 
teams/information Warfare), or any of the three previously mentioned paths, plus a feint 
at a different location, for a total of 6 possible major paths. 

(3) Multiple Outcomes: High-level desired outcomes for the 
given amphibious assault task are to (a) accomplish the objective, (b) achieve surprise, (c) 
suppress enemy positions at the beach, (d) minimize casualties, (e) interdict enemy 
reserves, (f) achieve sea supremacy, (g) achieve air superiority, and (h) minimize 
collateral damage, for a total of 8 desired outcomes. 

(4) Conflicting Interdependence Among Outcomes: Conflicts, 
and the scores for each, are shown in Table 1 (correlate letters on table with outcomes 
listed in paragraph above). It should be noted that the scoring in Table 1 is situationally 
dependent; conflicts between outcomes would vary in different amphibious operations. 
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Table 1. Scoring of Conflicting Interdependence Among Outcomes, Where Each Entry On Table 
Represents The Conflict Between The Outcomes Represented in Column i and Row j 


(5) Uncertain or Probabilistic Linkages: Depending on the 
situation and the accuracy and volume of intelligence available, this could vary from low 
to high. 


4. Coordination Requirements 
a. Definition 

Generally, coordination requirements is the degree to which dependencies 
between activities must be managed (Malone and Crowston, 1994, p. 90). This can be 
subdivided into external (the group with others) and internal (among members of the 
group) coordination. Four different types of dependencies that must be coordinated, and 
an example of each, are as follows: 

(1) Shared Resources. Who, among a group of actors, gets which 
available and common resources (Malone and Crowston, 1994, p. 92). 

(2) Producer/Consumer Relationships. When one member of a 
group uses the output of another, or a member of a group or the group as a whole uses the 
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output of another entity, or this other entity uses the group’s or a member of the group’s 
output (Malone and Crowston, 1994, p. 93). 

(3) Simultaneity Constraints. When two or more activities must be 
scheduled or synchronized (Malone and Crowston, 1994, p. 95). 

(4) Task/Subtask. Goal selection and/or task decomposition 
within a group and/or among groups (Malone and Crowston, 1994, p. 95). 

b. Levels 

A task would be given a grade for each of the four different types of 
dependencies listed above, and on both the internal and external level. Subjective grades 
such as High, Medium, Low, and None are probably most appropriate. Thus, each task 
would have eight coordination requirements grades associated with it. 

c. Example 

(1) Shared resources: Two light infantry units each face an enemy 
armored threat, and there is only one section of antitank helicopters that can be used 
against those threats, and it is attached to one of the infantry units. Coordination required 
would be graded as High (internal) and Low (external). If the antitank helicopter asset is 
owned by an external agent, however, coordination required would be graded as Low 
(internal) and High (external). 

(2) Producer-consumer relationships: During the conduct of an 
amphibious assault, mineclearing helicopters must be used to clear mines from the 
approach to the landing beach. The landing force, then, is the consumer of the 
mineclearing helicopters’ output. If we consider the “group” to be the amphibious task 
force, then coordination required would be High (internal) and Low (external). If we 
consider the “group” to be the landing force, however, then coordination required would 
be Low (internal) and High (external). 
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(3) Simultaneity constraints: During the latter stages of the same 
amphibious assault, an infantry unit must conduct an attack synchronized with close air 
support and naval surface fire support. If the “group” was considered to be the 
amphibious task force, the coordination required would be High (internal) and Low 
(external). If the “group” was considered to be the landing force, the coordination 
required would be Low (internal) and High (external). 

(4) Task/Subtask: A landing force commander is given a mission 
of taking a specific objective. He must then divide the task up into subtasks for his 
subordinate units to complete. The coordination required in this situation would be High 
(internal) and Low (external). 

5. Magnitude 

a. Definition 

The magnitude of a task is the number of activities or subtasks that must 
be performed in order to complete the task. 

b. Levels 

The magnitude of a task could be determined quantitatively by the number 
of activities that must be performed in order to complete the task. However, this requires 
a standardized definition of “activity,” such that one activity is as difficult to perform as 
another, and decomposition of the task to the point where all activities are identified. 
Another way to assess the magnitude of a task would be to use an anchored scale. For 
example, magnitude could be measured on a one to one hundred scale, with “one” 
representing the task of pressing the spacebar on a typev^iter, and “one hundred” 
representing the task of constructing the United States Interstate Highway System. 

c. Example 

The task of conducting an amphibious assault has many different activities 
or subtasks that must be performed, such as clearing the beach, making a reconnaissance. 
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suppressing artillery with close air support, et cetera. On the one to one hundred scale 
mentioned above, the score would be about 30 for a significant amphibious assault. 

6. Resources Required 

a. Definition 

Resources required to complete a task is defined as the resources other 
than information that the actors must possess in order to successfully complete the task in 
question. 


b. Levels 

Resources required could be measured quantitatively by the number of 
resources required to complete a task, or could be graded on a subjective “High, Medium, 
and Low” scale. As is the case with magnitude, one must take care to ensure that there is 
a standard definition of resource, so that five resources in one instance is the same as five 
resources in another. 


c. Example 

A landing force is given the mission of attacking an objective, and that 
objective requires three infantry companies to effectively overwhelm it. If the “base unit” 
of resources is one infantry company equivalent, then resources required to complete this 
task is three. 

7. Information Required 

a. Definition 

Information required to complete a task is the information that the actors 
must possess in order to successfixlly complete the task in question. 

b. Levels 

Information required is measured using the same method as resources 

required. 
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c. Example 

A Silkworm anti-ship missile site threatens an aircraft carrier battle group. 
However, it was reported in a residential area, so additional information (confirmation 
and precise location via U-2 imagery) is required before the commander can destroy that 
threat. If the base unit of information is one intelligence report, then information required 
to complete this task is two reports, the initial report and the confirmation report. 

8. Task Formalization 

a. Definition 

Task formalization is the level of specification and structure exhibited by 
the task (Davis et al., 1991, p. 22). A task with high formalization is defined in a very 
structured way; there are certain well-defined activities that must be performed in a 
definite sequence in order to complete the task. In a task with low formalization, though, 
the activities required to complete the task, and possibly even the goals of the task, are 
poorly defined and open to interpretation. 

b. Levels 

This dimension is again quite subjective, and the levels should probably be 
High, Medium, Low, and None, or some other discrete scale. 

c. Example 

The task of calling for artillery fire against a visible target is very well 
structured. There are precise procedures that the forward observer must follow, using 
specific radio nets and message formats, that are ingrained from his earliest training. Task 
formalization for an artillery call for fire is High. However, the task of infiltra ting enemy 
lines and destroying a prepared defensive position is not well structured — there are 
many ways that the task could be carried out, and the methods used and paths taken are 
not well formalized, but situationally dependent. Task formalization for the infiltration 
task is Low. 
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9. Dynamicity 


a. Definition 

The dynamicity of a task is the degree to which one or more of the 
dimensions of the task changes over time. Dynamicity could refer to any of the 
dimensions described above, alone or in combination with others. 

b. Levels 

This is quite subjective, and would probably best be graded as High, 
Medium, Low or None in each dimension, or possibly the number of changes per unit 
time in each dimension, if that is measurable. 

c. Example 

Returning to our amphibious assault example, consider the task of 
conducting the assault across the beach. If the assault was conducted while the 
amphibious task force was still over the horizon, and retained the element of surprise, the 
task would be much different than if it was conducted later, when the amphibious task 
force was in view of the objective beach, and the element of surprise was lost. The later it 
was conducted, the better prepared the enemy would be for the assault. In each 
dimension, dynamicity is graded as follows: 

Uncertainty: High (The later the assault is conducted, the less uncertainty) 

Time Pressure: High (The later the assault is conducted, the more time pressure) 
Complexity: High (The later the assault is conducted, the more complexity) 
Coordination Requirements: High (The later the assault is conducted, the more 
coordination required) 

Magnitude: High (The later the assault is conducted, the greater the magnitude) 
Resources Required: High (The later the assault is conducted, the more resources 
required) 

Information Required: High (The later the assault is conducted, the more 
information required) 
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Task Formalization: Low 


D. EXCEPTIONS TO ORTHOGONALITY 

The dimensions described in the preceding section are distinct, but, unfortunately, 
related. However, if the interrelations between dimensions are known, compensation for 
the interaction can be made in order to keep dimensions the experimenter wants to remain 
constant from varying. This section will discuss how one might expect changes in one 
dimension to affect all other dimensions. 

There should be little or no interaction between uncertainty and dynamicity, time 
pressure and dynamicity, complexity and dynamicity, coordination requirements and task 
formalization, coordination requirements and dynamicity, magnitude and task 
formalization, magnitude and dynamicity, resources required and task formalization, 
resources required and dynamicity, information required and task formalization, 
information required and dynamicity, or task formalization and dynamicity. All other 
interactions are detailed below. 

1. Uncertainty-Time Pressure 

As uncertainty increases, the number of activities that an actor would have to 
perform in order to deal with the uncertainty well enough to complete the task could also 
increase (increased magnitude). If this number of activities increases while the time 
allowed to perform the task remains constant, time pressure will increase. Conversely, if 
time pressure increases, it could force the actor to complete the task before he is able to 
obtain all the information he wants, thus increasing uncertainty. 

2. Uncertainty-Complexity 

As uncertainty increases, complexity can also increase. The number of attributes 
that must be taken into account in order to reduce uncertainty can increase, thus causing 
greater complexity. Additionally, if the uncertainty decreases the probability of the 
linkages between path activities and desired outcomes, this can cause an increase in 
complexity. Conversely, if the complexity increases, it should not necessarily affect the 
uncertainty. 
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3. Uncertainty-Coordination Requirements 

Changes in uncertainty can cause changes in coordination requirements. If 
uncertainty increases, whether resources must be shared, which activities must be 
simultaneous, what must be produced and consumed, or which subtasks are required in 
the performance of a task can also become more uncertain, requiring greater coordination 
for any type of dependency in which the uncertainty is increased. Conversely, changes in 
coordination requirements should not cause changes in uncertainty. 

4. Uncertainty-Magnitude 

As mentioned under “time pressure,” as uncertainty increases, the number of 
activities that an actor must perform in order to alleviate the uncertainty could increase, 
thus increasing the magnitude of the task. Conversely, an increase in magnitude could 
force the actor to complete the task before he is able to obtain all the information he 
wants, thus increasing imcertainty. 

5. Uncertainty-Resources Required 

As uncertainty increases, resources required could increase, if those resources 
would be used to decrease the uncertainty or, in a case that involves two or more uses for 
certain resources, the uncertainty is enough so that the decisionmaker desires to use 
resources for all potential paths, in order to “cover all bets.” An increase in resources 
required would not tend to drive an increase in uncertainty, however. 

6. Uncertainty-Information Required 

As uncertainty increases, information required could also increase, because the 
decisionmaker would want more information in order to reduce his uncertainty. Changes 
in information required, though, should not cause changes in uncertainty. 

7. Uncertainty-Task Formalization 

Increases in uncertainty could also elicit increases in task formalization, since the 
uncertainty can involve the structure and paths taken to complete the task. This is not 
necessarily so, however; a task can still be highly formalized and well structured if some 
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or many of the states, inputs, outcomes, or environments are not well known. Changes in 
task formalization should not drive changes in uncertainty, however. 

8. Time Pressure-Complexity 

Changes in time pressure can cause changes in complexity. If the time pressure 
decreases, the number of attributes or paths that can be considered can increase, because 
of the additional time the decisionmaker has to consider them. Also, uncertain or 
probabilistic linkages can decrease if time pressure decreases, because the decisionmaker 
has additional time to reduce his uncertainty. Conversely, changes in complexity can 
cause changes in time pressure. If complexity decreases, the amount of time that the 
decisionmaker must devote to sorting out the situation also decreases, and, if the amount 
of time available remains constant, time pressure will decrease. 

9. Time Pressure-Coordination Requirements 

Changes in time pressure can affect coordination requirements. If the time 
pressure increases, coordination between two or more entities can become more difficult, 
or even impossible, because the time available to communicate and synthesize is 
lessened. Conversely, changes in coordination requirements can cause changes in time 
pressure. If coordination requirements are lessened, the amount of activities that must be 
performed is generally lessened, because some of those activities are 
coordination-related, such as the actors communicating with one another. Lessening the 
number of activities while holding the time available constant reduces time pressure. 

10. Time Pressure-Magnitude 

Since time pressure and magnitude are directly related (time pressure is 

magnitude divided by time available), changes in one will cause changes in the other, 
unless the time available is modified accordingly. 

11. Time Pressure-Resources Required 

Changing time pressure would tend to have an inverse effect on resources 
required. If time pressure was increased, the resources required would tend to go down. 
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because the actors would not have time to use all the resources that are available to them. 
Changes in resources required would tend to have a direct effect on time pressure — if 
resources required was increased, then time pressure would increase, because of the 
additional activities that would probably be required to put those resources to use, as long 
as time available is held constant. 

12. Time Pressure-Information Required 

This interaction should be the same as the time pressure-resources required 
interaction. 

13. Time Pressure-Task Formalization 

As time pressure is increased, task formalization would tend to increase, in those 
instances where there is a more structured way to perform a task that may not achieve the 
goals of the decisionmaker as well as a less structured method will, but the more 
structured method would tend to take more time. As task formalization is increased, time 
pressure would tend to decrease, because more formalized tasks would tend to take less 
time because of the well-defined nature of the activities involved. 

14. Complexity-Coordination Requirements 

Complexity and coordination requirements can affect each other in many subtle 
ways. For instance, if the number of possible paths is increased, coordination 
requirements could be increased, because of a possible requirement to coordinate with 
other team members in order to explore the paths. Or, increasing a shared resources 
requirement could increase the number of possible paths that could be taken. Changes to 
either of these dimensions must be scrutinized carefully to ensure any effect on the other 
has been accounted for. 

15. Complexity-Magnitude 

Increasing complexity can increase the magnitude of a task. If, for instance, 
additional activities must be performed in order to resolve a complex issue, then 
magnitude will increase. Additionally, if the magnitude of a task changes, and the added 
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or decreased activities affect the number of attributes, paths, outcomes, interdependence, 
cues, or linkages present, then the complexity could increase or decrease as wfell. 

16. Complexity-Resources Required 

Increasing complexity of a task might require a different system or more 
personnel to aid in problem-solving than a more simple task would, thus increasing 
resources required. If resources required to complete a task were decreased, then 
complexity could decrease also, because the decrease in resources required could result in 
fewer attributes or paths that must be considered by the decisionmaker. 

17. Complexity-Information Required 

Increasing the complexity of a task could increase information required, because 
the decisionmaker might want more information in order to help choose the right path, or 
decrease uncertainty of linkages between paths and outcomes. Increasing the information 
required could also increase task complexity, because the additional information required 
could be an additional attribute that the decisionmaker must consider. 

18. Complexity-Task Formalization 

Increasing complexity can decrease task formalization. As the number of 
attributes, paths, and desired outcomes grows, the chore of formalizing a task can become 
more difficult, such that many extremely complex tasks are not formalized at all, because 
of the number of characteristics that must be considered. Increasing task formalization 
may or may not increase complexity. Increasing formalization and adding a structured 
way of looking to the decisionmaking process could have the effect of decreasing 
complexity, or at least making the complexity more easily manageable. 

19. Coordination Requirements-Magnitude 

Increasing coordination requirements could increase the magnitude of a task, 
because greater coordination requirements could result in additional activities that must 
be performed in order to coordinate actions. Changes in task magnitude, however, should 
have little or no effect on coordination requirements, unless the activities that were added 
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or deleted specifically involve use of shared resources, a producer/consumer relationship, 
a simultaneity constraint, or the task must be decomposed into subtasks by the 
decisionmakers. 

20. Coordination Requirements-Resources Required 

Changes to the coordination requirements should not affect resources required to 
perform a task. Increases in resources required, though, could cause coordination 
requirements to increase, because the additional resources required could cause a 
necessity to share available resources where one did not exist before, unless the resources 
available were also increased. 

21. Coordination Requirements-Information Required 

Changes to coordination requirements should not affect information required. 
Increases in information required could lead to increases in coordination requirements, 
because the decisionmakers might need to coordinate actions in order to obtain the 
additional information. 

22. Magnitude-Resources Required 

Changes in the magnitude of a task should not affect resources required to 
complete a task, unless the added activities require more resources to perform them. 
Changes in resources required, however, could change the magnitude of a task, if the 
additional resources needed additional activities to be performed in order to put the new 
resources to use. 

23. Magnitude-Information Required 

Changes in the magnitude of a task should not affect information required to 
complete a task, unless the added activities require more information in order to perform 
them. Changes in the information required, however, could change the magnitude of a 
task, if the actors had to perform additional activities in order to obtain the added 
information. 


31 


24. Resources Required-Information Required 

Changes in resources required to complete a task could cause changes in 
information required, if the additional resources needed additional information in order to 
put the resources to use. Conversely, changes in information required to complete a task 
could result in changes in resources required, if the new information requirement needed 
additional resources in order to obtain the information. 

E. SUMMARY 

The purpose of this chapter was to enumerate dimensions of task structure, define 
them, and develop a method of grading the dimensions, so these dimensions can be held 
constant or varied in an experimental environment. The chapter began with a review of 
the pertinent literature, surveying the possible sources of information and different 
opinions on dimensions of task structure. These dimensions were then compiled, revised, 
and extended into what the author believes is a comprehensive breakdown of the 
dimensions of task structure. A summary of these dimensions, and the levels at which 
they can be graded, is included in Table 2 below. 

Examples of each dimension were then given, and graded using the scale that was 
developed. Finally, the author described exceptions to the requirement that the 
dimensions be orthogonal to one another, to aid in adjusting for any effect changing one 
dimension might have on other dimensions. 
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Dimension 

Uncertainty 
Time Pressure 


Complexity 

- Multiple Attributes 

- Multiple Paths 

- Multiple Outcomes 

- Conflicting Interdependence Among 
Outcomes 

- Uncertain or Probabilistic Linkages 

Coordination Requirements 

- Shared Resources 

- Producer/Consumer Relationships 

- Simultaneity Constraints 

- Task/Subtask 


Levels 

High, Medium, Low, None 

High, Mediiun, Low, None 
Magnitude/Time Available) 


Number of attributes 
Number of paths 
Number of outcomes 
Number of conflicts, levels of each, 
totaled for task 
High, Medium, Low, None 

For all types of dependencies: 

High, Medium, Low, None, for internal 
and external coordination 


(or 


Magnitude 
Resources Required 
Information Required 
Task Formalization 
Dynamicity 


Number of activities or subtasks 

Number of resources required 

Number of pieces of information required 

High, Medium, Low 

High, Medimn, Low for each dimension 


Table 2. Dimensions of Task Structure 
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III. TASK STRUCTURE DIAGRAM AND TASK DESIGN PROCESS 


A. INTRODUCTION 

As discussed in the previous chapter, determination of the dimensions of task 
structure is an important aspect of experimental design involving task structure, since it 
provides the groundwork for varying or controlling tasks based on dimensions. Once 
those dimensions are defined, it would be of further assistance to the experimenter to 
develop a method for visually describing the task structure, flow, and as many of the 
dimensions defined in the previous chapter as possible. A visual method of this sort 
would make the undertaking of causing tasks to differ or remain constant in various 
respects simpler. 

The focus of this chapter is the development of a task structure diagram concept. 
First, I will give some preliminary definitions necessary to the discussion of 
decomposition of tasks into component subtasks and actions. I will then describe the task 
structure diagram that I developed, and define the specific features and capabilities of the 
diagram. Then, I will describe how the dimensions of task structure developed in the 
previous chapter relate to the diagram. Finally, I will synthesize the concepts of Chapter 
II and this chapter into a task design process that can be used to develop a military 
operational scenario, or more general task, in an experimental context. 

B. DEFINITIONS 

Because the development of a task structure diagram will involve decomposing 
tasks into the smaller activities of which they are constituted, it is necessary to define 
exactly what those different activities should be called, and to define task structure and 
the task structure diagram. These definitions apply throughout this thesis. 

1. Activity 

An activity is any act that must be performed, at a high or low level of task 
decomposition. For our purposes, it is a generic term encompassing tasks, subtasks, and 
actions. 
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2 . 


Task 


A task is the macro level activity. It describes the overall activity that is being 
performed by the actors. Since it is really impossible to define beforehand the magnitude 
of the task, for our purposes, it is defined as the level that is the primary focus of the 
study. 

3. Subtask 

A subtask is a next-lower level component of a task. The nodes on a task structure 
diagram are subtasks. There can be more than one level of subtasks; if there are multiple 
layers, the highest layer of subtasks is subtask level 1. 

4. Action 

Actions are activities that are in their most elemental state for the uses of the 
study. Actions are either not further decomposible, or further decomposition would be 
impractical or would serve no purpose. 

5. Task Structure 

Task structure is defined as the flow of subtasks within a task in the time domain. 

6. Task Structure Diagram 

A task structure diagram is a visual model of a task which describes the task 
structure, and as many characteristics of a task as practical. The task structure diagram is 
designed to simplify understanding of the task and manipulation of potential variables. 

C. TASK STRUCTURE DIAGRAM 

The task structure diagram I developed is based loosely on the data flow diagram 
(DFD) concept (Hatley and Pirbhai, 1988, p. 13). The purpose of this task structure 
diagram is to provide a visual representation of the flow of subtasks and actions, possible 
paths, simultaneity constraints, competition, prerequisites, resources and information 
required, decomposability, and dynamicity of subtasks within a task to experimental 
designers. Many of the dimensions of task structure in the previous chapter are 
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represented directly in this task structure diagram; others can be inferred from it. By 
visualizing the structure of a task in this way, experimenters are more able to determine if 
that task accomplishes the objectives that have been set. In addition, the task structure 
diagram provides a straightforward, visual method for comparing it with other tasks and 
for describing a task to those outside the scenario design process. This method also 
enables design from the other direction — experimental designers can delineate a task 
structure that they are interested in testing, and the scenario can be written to conform to 
that structure. It further promotes the “object oriented” view of task structure design, 
allowing designers to rearrange activities and nodes visually, as modules, to achieve 
experimental goals. 

Clearly, tasks with high levels of task formalization, or highly structured tasks, are 
most easily described by this type of method. As one moves down the scale from high 
formalization to low, the possible paths that could be taken grow exponentially, until a 
point is reached where the labor involved in developing this sort of diagram outweighs 
the benefits to be gained from its use. Figure 2 is an example of the task structure diagram 
developed in this chapter. The primitives, or building blocks, of the proposed method are 
described below. 

1. Flow Description 

In this method, the task is considered to encompass the entire diagram; the 
individual subtasks are the nodes, represented by the circles or rectangles. The task flows 
in time from the “start” box to the completion of the final subtask. 

2. Actors 

The actor who is performing each subtask in Figure 2 is represented by the style 
of type used for the name of the subtask. If the subtask is given in bold type, then Unit 1 
is the task performer, while if the name of the subtask is given in italic type, then Unit 2 
is the task performer. If the subtask is in normal type, then both actors are involved in the 
subtask. If there are more than two actors involved in a task, then different combinations 
and fonts would have to be used. 
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Figure 2. Task/Subtask Level Task Structure Diagram 


3. Decomposability 

Decomposability is defined as the ability to further divide the task, subtask, or 
activity into lower level subtasks or actions (Simon, 1981, pp. 196-210). 
Decomposability is represented by the border of the rectangle or oval representing each 
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activity. If the border is solid, that means the subtask is not decomposible — the task, 
subtask, or action represented is at its most basic level. If the border is a dotted line, then 
the activity can be further decomposed. 

4. Simultaneity 

Simultaneity, from Chapter II, is defined as the requirement for two or more 
activities to be performed at the same time or synchronized, and is a type of dependency 
between actions that is encompassed within the aegis of coordination requirements. 
Simultaneity is represented by a thick bar connecting the two activities that have the 
dependency relationship. 

5. And Operator 

The And operator is represented in the diagram by a half-moon shape. It 
represents the requirement for both of the previous activities to be completed before the 
next can be performed. 

6. Or Operator 

The Or operator is represented in the diagram by a crescent shape. It represents 
the requirement for either one of the previous activities to be completed before the next 
can be performed. 

7. Competition 

Whether an activity is competitive or non-competitive describes another of the 
coordination requirements dependencies, shared resources. A competitive task is one in 
which two or more actors need the same resource to complete the task. Competition over 
resources is represented in the diagram by underlining the title of the activity; if the title 
of the activity is not underlined, then there is no competition over resources for that 
activity. 
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8. Dynamicity 

Dynamicity, from Chapter II, is the degree to which one or more of the 
dimensions of a task changes over time. Dynamicity is represented in the diagram by the 
shape of the figure representing the activity. Rectangles represent non-dynamic, or static 
tasks, and ovals represent dynamic tasks. 

9. Prerequisites — Hard And Soft 

Prerequisites are the activities that are to be performed prior to a given activity. If 
it is not possible to perform the given activity without the prerequisite being performed 
first, then that prerequisite is considered a hard prerequisite. If it is possible, but not 
optimal, to perform the given activity without the prerequisite being performed first, then 
that prerequisite is considered a soft prerequisite. A hard prerequisite is represented in the 
diagram by a solid arrow connecting two activities, while a soft prerequisite is denoted by 
a dashed arrow connecting two activities. 

10. Decomposing Tasks Into Subtasks And Actions 

Figure 2 shows a task decomposed into subtasks. Some of the subtasks shown are 

in their elemental state — they are not further decomposible. Most, though, can be 
decomposed at least one level. Figure 3 shows a subtask decomposed into its component 
actions. 

The task structure diagram in the elemental state follows the same format as the 
previously discussed task structure diagram. The only significant differences are that the 
task structure diagram in the elemental state also contains the breakdown of the 
dimensions of task structure that apply to each action that are not otherwise manifested in 
the task structure diagram (if they are graded as other than “Low” or “None”), and the 
resources and information required to complete the action. 
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Subtask 3 


Unit1 

Unit 2 
Common 
Competitive 
ODynamic 
" Decx)mposible 
^•Parallel Tasks 
Operator 


Figure 3. Subtask Decomposed To Its Most Basic Components 


D. OPERATIONALIZING DIMENSIONS OF TASK STRUCTURE IN A 
TASK STRUCTURE DIAGRAM 

An important consideration for both the task structure diagram just discussed and 
the dimensions of task structure enumerated in the previous chapter is the linking of the 
two issues. How is each dimension of task structure implemented in the task structure 
diagram? Implementation of some dimensions is straightforward, while others must be 
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handled more subtly. This section describes how each of the nine dimensions of task 
structure is manifested in the task structure diagram. 

1. Uncertainty, Time Pressure, Complexity 

Uncertainty, time pressure, and complexity are manifested in the task structure 
diagram by the level that each is given in the diagram that decomposes a task into its 
most elemental state, as shown in Figure 3. The overall score for a subtask in each of 
these dimensions is the mean of all scores of the actions that comprise the subtask; the 
overall score for a task in each dimension is the mean of all scores of the subtasks that 
comprise the task. 

2. Coordination Requirements 

Coordination requirements are manifested in several ways in the task structure 
diagram. First, if the grade for each type of dependency is Fligh or Medium, this will be 
listed with the action at which it is present on the diagram that decomposes the task to its 
most elemental state. In addition, the individual dependencies are represented separately 
in the diagram as follows: 

a. Shared Resources 

In Figure 2, subtasks that are underlined are competitive events. This is 
synonymous with competition over shared resources. When activities are imderlined, 
competition over shared resources is Medium or High. 

b. Producer/Consumer Relationships 

The presence of a hard prerequisite indicator (solid arrow coimecting two 
activities) in a task structure diagram implies that a producer/consumer dependency 
exists, since the follow-on activity cannot be performed until the first is complete. When 
the solid arrow is present, the producer/consumer dependency is graded as Medium or 
High. 
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c. Simultaneity Constraints 

Simultaneity is represented in the task structure diagram by a solid bar 
connecting the activities that have the dependency relationship. When the solid bar is 
present, simultaneity constraints is graded as Medium or High. 

d. Task/Subtask 

While the task structure diagram captures the breakdown of a task into its 
component subtasks and actions, this is not the same as the conscious decomposition of 
the task by the actors into portions for each to accomplish which the task/subtask 
dependency represents. The task/subtask dependency is not manifested in the diagram 
itself, other than the grade given in the diagram that decomposes the task to its most 
elemental state. 

3. Magnitude 

The magnitude of a task can be measured from the task structure diagram by 
breaking the entire task down into its most elemental state and generating one or more 
diagrams similar to Figure 3. Counting the total number of actions in these diagrams 
gives the task’s magnitude. 

4. Resources And Information Required 

Resources and information required are given in the diagram that decomposes the 
task to its most elemental state. Counting the total resources and pieces of information in 
the diagram(s) representing the totality of actions within the task gives the total resources 
and information required for the task. 

5. Task Formalization 

A task that is amenable to description using the task structure diagram will 
probably have at least a Medium level of task formalization. Indicators of formalization 
in the diagram are the relative number of soft and hard prerequisites (more soft 
prerequisites would imply less formalization), and the number of “or” operators (more 
“or” operators implies less formalization). 
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6. Dynamicity 

Dynamicity, as discussed earlier, is manifested in the task structure diagram by 
the shape of the node representing the activity. 

E. TASK DESIGN PROCESS 

The activities described in this and the previous chapters can be applied to the task 
design and scenario development problem stated in Chapter I in a straightforward 
manner. The steps in the process are: determining the dimension of task structure of 
interest, determining the desired task structure, developing the scenario, and grading 
scenarios by dimensions. The second and third steps can be interchanged. This process 
will often be iterative, with at least the second, third, and fourth steps repeated one or 
more times. 


1. Dimension of Interest 

Determining the dimension(s) of task structure of interest depends on the goals of 
the experiment. Of course, in order for there to be a task structure dimension of interest, 
task structure must be an independent variable. For example, if a researcher wanted to 
determine whether larger or smaller tasks were performed better by a certain 
organizational structure in a specific environment, then his dimension of interest would 
be magnitude. He should also determine the number of levels he will need ahead of time, 
based on the constraints of his experiment, and at least an approximate figure for the 
values the levels will take on. 

The researcher should also determine the levels of any of the other dimensions of 
task structure that he desires to hold constant, if that is important to his investigation. 

2. Desired Task Structure 

If a certain structure within the task-subtask-action decomposition, or one of the 
characteristics that is best reflected in a diagram (such as parallelism), is desired, then a 
preliminary task structure diagram should be developed after the dimension of interest 
has been determined, with detail filled in as the scenario is written. If there is no specific 
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task structure requirement for the experiment, then the task structure diagram should be 
developed concurrently with the scenario, to be used as a briefing, explanation, editing, 
and grading tool. 

3. Scenario Development 

The scenario should be developed based on the above two steps, and to fit within 
the other constraints of the experiment, such as project context, other independent 
variables, subject pool, time and resources available, et cetera. 

4. Grading Dimensions of Task Structure in Scenarios 

Finally, the scenario(s) should be graded based on the levels of dimensions of task 
structure described in Chapter II, in order to ascertain whether these dimensions differ or 
are held constant as was intended. 

F. SUMMARY 

This chapter further developed the concepts of the previous chapter by stipulating 
a method by which a task’s structure can be visually represented. This diagram not only 
depicts the dimensions of task structure, but also shows the flow of subtasks and actions 
in the time domain, and represents optional paths, prerequisites, and decomposability. 
The chapter began with several definitions necessary in order to discuss task 
decomposition. Then, the task structure diagram and its features were described, and the 
manifestation of the dimensions of task structure in the task structure diagram were given. 
Finally, the work of the last two chapters was synthesized and a task design process was 
described, giving a straightforward approach for designing a military operational scenario 
based on task structure. 
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IV. SCENARIO DEVELOPMENT FOR THE FIRST A2C2 EXPERIMENT 

A. INTRODUCTION 

Chapters II and III focused on enumerating and determining levels of dimensions 
of task structure, development of a paradigm for visually representing task structure, and 
stipulation of a process for designing a task based on the dimension of interest and 
desired structure. This chapter returns to the A2C2 context in which this thesis is written. 
Recall from Chapter I the original problems of determining the dimension of task 
structure to be varied, the structural form the task will take, and development of a 
scenario and variants to fit within those constraints for the initial experiment within the 
A2C2 project. These issues will be dealt with in this chapter, using the tools developed in 
Chapters II and III. I will also describe the conduct of that initial experiment, and 
operationalization of the task and organization structures. 

B. DETERMINATION OF THE DIMENSION OF INTEREST 

1. Background 

It was stated in Chapter I that the specific dimension of interest for the first 
experiment with regard to organizational structure was levels of hierarchy, and whether 
there are circumstances in which a flattened organizational structure would tend to 
outperform a more hierarchical structure, and vice versa. An issue that arose several times 
during the A2C2 field research concerned these circumstances. The organizational 
structure used in the joint officer interviews was relatively “flat,” and several of the 
officers saw reasons to add a layer of hierarchy, typically when one force might need 
assets that belonged to another (a shared resources dependency under the dimension of 
coordination requirements, from Chapter II). The extra layer of hierarchy would 
presumably facilitate coordination when two units were competing over one another’s 
assets. The same question came up in field visits to warfighting commands. 
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Research Issue and Hypotheses 


Based on the field research and my work in defining dimensions of task structure 
in Chapter II, the A2C2 team formulated a general research issue: can tasks differ in 
coordination requirements in such a way that an organization structure with more layers 
is better for some tasks, and a structure with fewer layers is better for others? From that 
research issue, our general hypothesis developed: there is an interaction between task 
structure and organization structure, when coordination requirements and levels of 
hierarchy are the respective dimensions of interest. More specifically, when two units in 
the same functional area must coordinate the use of assets in order to process their 
individual tasks: 

• An organization with a common functional commander is better when the 
assets are owned by one of the two units, whereas 

• An organization without a common functional commander is better when the 
assets are owned outside of the functional area. 

The reasoning behind the first assertion is that placing an experienced component 
commander over all forces in a functional area will focus those forces on a common 
mission or goal. The subordinate commanders will be more likely to make decisions that 
are optimal for the component as a whole, and if they do not, the common commander, 
with his component-centric focus, will be able to mitigate conflicts within the component 
in a timely manner. The overall commander, on the other hand, is poorly positioned to act 
as the common commander. He focuses at a higher level, considering the air, ground, and 
naval context as a whole. He is too busy with command and control of the overall 
operation to narrow his focus and mitigate conflicts within a component in a timely 
manner. 

On the other hand, when a lower level commander in one functional area needs an 
asset that belongs to the overall commander (or his superiors), and that asset might also 
be needed by a unit in another functional area, the overall commander must become 
cognizant of the specific needs within the functional area before he allocates the asset. If 
the overall commander and the lower level units all share a common operational picture, 
the overall commander will not, in theory, need component commanders to apprise him 
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of the seriousness of their respective units’ needs before he makes his decision. If lower 
level commanders have a common operational picture, they presumably should be able to 
act in a more autonomous manner to achieve the commander’s intent and allocate 
resources among themselves. As a result, the overall commander should be able to 
increase his span of control and the organization can become “flatter.” 

3. Dimension of Interest 

Based on the above research issue and hypotheses, the task structure dimension of 
interest was the “competition over shared resources” subcategory of coordination 
requirements. It was presented at two levels, level one is high internal competition over 
shared resources (competition over organic assets), level two is high external competition 
over shared resources (competition over non-organic assets). It was desired that all other 
dimensions of task structure remain constant. The factors for the final 2x2 experimental 
design, then, became organization structure (two-tiered hierarchy versus three-tiered 
hierarchy) and task structure (competition over organic assets versus competition over 
non-organic assets). 

C. DESIRED TASK STRUCTURE 

The A2C2 team also had specific ideas about the structural characteristics of the 
desired task, and levels of other dimensions that would allow for optimum accessibility to 
the task and organization structure dimensions of interest. 

1. Formalization 

A high degree of formalization was considered desirable. The researchers wanted 
there to be a consistent structural form to the task, and replicable events which would 
occur in each task requiring each team of subjects to compete over the same resources in 
identical circumstances. Crucial to this requirement was the need for “one-of-a-kind” 
resources. Normally, any military force has a certain amount of robustness built in — 
there is generally more than one asset that can perform a given mission. For example, in 
an aircraft carrier battle group, there are any number of weapons, from aircraft to frigates 
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to destroyers, which can engage fast patrol boats. However, if that multiplicity of assets 
had been allowed in this experiment, then each team of subjects would have, in effect, 
created its own task structure, potentially completing tasks while avoiding the 
competition that was the point of the experiment. 

2. Prerequisites 

In spite of the desire for high formalization, the experimental designers wanted 
the subjects to be free to make some errors, particularly involving the competition events 
— the subjects needed to be able to make the wrong decision. As such, prerequisites 
leading up to the competition events tended to be hard, and prerequisites within the 
competition events themselves tended to be soft. In execution, though, there were 
exceptions to this rule, which occasionally resulted in the desired competition events not 
occurring, or occurring in ways that the experimental designers had not anticipated. 

3. Separability of Maritime and Ground Portions 

The experimental designers envisioned a scenario involving a joint task force 
(JTF) with two components under the JTF, a maritime component and a ground 
component, each component further comprised of two lower-level units. Recall from 
Chapter 1 that the two levels of organizational structure to be tested in this experiment 
were two-tiered and three-tiered. Although the two-tiered and three-tiered structures were 
separated for analysis, the two JTF organizations that were used for the experiment each 
had an intermediate commander supervising one component and none supervising the 
other. Thus, in half of the runs there was a ground component commander (GCC), while 
in the other half there was a maritime component commander (MCC), as shown in Figure 

4. This was done in order to keep the number of subjects constant across all trials, and 
avoid task-load-per-individual problems that would have arisen had the two structures 
been composed of different numbers of subjects. 
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Figure 4. Organizational Structures Used In Experiment 


A goal of the design team was for the competition events in the scenario to be 
modular with regard to the components; competition events should not occur across 
components, but between the two lower level units within each component. A module 
was then defined as that portion of a scenario that affected one component. A desired 
result of this separation of ground and maritime competition events was a potential 
doubling of the number of data points, since two sets of competition scores per 
experimental run would then be received. A complete scenario was composed of two 
modules — one maritime and one ground. The modules were numbered as follows: 

• Module 1: Competition Between Ground Units for Organic Assets 

• Module 2: Competition Between Ground Units for Non-Organic Assets 

• Modules: Competition Between Maritime Units for Organic Assets 

• Module 4: Competition Between Maritime Units for Non-Organic Assets 

Modules 1 and 3 were combined to form Scenario 13, competition for organic 

assets (level one), and Modules 2 and 4 were combined to form Scenario 24, competition 
for non-organic assets (level two). 

The designers further wanted the task structure of the ground and maritime 
modules to be as similar as possible, within levels; the Module 1 task structure diagram 
should look like the Module 3 diagram, and Module 2 should likewise resemble Module 
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4. This proved to be difficult, because of the basic difference in the ground and maritime 
missions that will be discussed in a later chapter. 


D. SCENARIO DEVELOPMENT 

The scenario for the first experiment was adapted from the scenario used for the 
joint officer interviews (Alphatech, Inc., 1995). My goal was to design two variants of 
the same scenario, one to be used as level one (Scenario 13) and the other as level two 
(Scenario 24), identical except for the competition events. 

What follows is a detailed description of the scenarios I developed, including the 
general situation, enemy situation, firiendly forces and asset ownership, mission, how the 
mission will be executed by fnendly forces, fi-iendly force priorities, the manner in which 
each variation of the scenario should unfold, and the scenarios used for training the 
subjects. 

1. General 

Orange, a North African nation friendly to the United States, is under attack by 
Green, whose forces have taken control of Orange’s port of Eastport. A Joint Task Force 
(JTF) is organized by a notional theater commander in chief, the Commander in Chief, 
Mediterranean Command (CINCMED), in order to capture the port and airfield of 
Eastport to allow for the introduction of follow-on forces. CINCMED’s ultimate purpose 
will be to drive Green forces from Orange and destroy their capability for offensive 
warfare. The Commander, JTF (CJTF) has at his disposal an aircraft carrier battle group 
(CVBG), an amphibious ready group (ARG) large enough to transport two Marine 
Expeditionary Units (Special Operations Capable) (MEU(SOC)), and two separate MEU 
(SOC)s. Figure 5 gives a representation of the Eastport area. 
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2. Enemy Situation 

A helibome or across the beach assault directly into the port of Eastport would be 
too risky beeause of obstructions, mines, obstaeles, and the presence of hidden enemy 
among the port facility buildings armed with handheld surface-to-air missiles. About 5 
miles south of the port, there are two suitable landing beaehes. There is a road leading 
from the northernmost beach (designated “Red Beach”) to the port, and another leading 
from the southernmost beach (designated “Blue Beach”) to the airfield. The waterborne 
approaches to the beaehes are possibly mined, and a piece of commanding terrain to the 
north of Red Beach is occupied by an enemy heavy mortar platoon with a platoon of 
infantry for security. This commanding terrain dominates both Red Beach and the port, 
and must be taken and held throughout any attack on Red Beach or the port. 

Known to be at the port, but hidden from view, is a company-sized mechanized 
counterattack force that could move toward Red Beach to try to foil any amphibious 
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assault. It is possible that there is a similar counterattack force at the airfield, which is 
located about 5 miles inland from Blue Beach. The counterattacking forces could inflict 
serious damage if they are not interdicted before they arrive at either beach once they 
begin movement. The off-road terrain between the beaches, port, airfield, and 
commanding terrain is swampy and treacherous, and is unsuitable for travel. Thus, all 
travel must be on the two roads. It is suspected that one or both of the roads will be 
mined, but the locations of any minefields are unknown, and will not be known until 
friendly units approach them. These “pop-up” minefields must be breached by engineers 
before the friendly forces can move beyond them. 

The port, airfield, both roads, both beaches, and the commanding terrain are 
located within range of two artillery strongpoints, one about 10 miles northwest of the 
port, and the other about 10 miles south of the airfield. The northernmost strongpoint can 
range Red Beach and the port, and the southernmost strongpoint can range the airfield 
and Blue Beach. Both are within range of two Naval Surface Fire Support (NSFS) 
stations off the port — one in support of MEU 1, and the other in support of MEU 2. The 
artillery pieces at both strongpoints are housed in reinforced concrete bunkers, and the 
ammunition stored in deep underground bunkers, so it is unlikely that even concentrated 
air attacks by the assets under the JTF’s control will completely disable the artillery 
strongpoint. When the enemy wants to fire an artillery barrage, they wheel out the 
artillery pieces, set them up, and fire within 15 minutes. If friendly forces can get 
effective NSFS on target in less than 15 minutes, the enemy will wheel their artillery 
pieces back into their bunkers and wait until another time. 

The enemy also has several FROG surface-to-surface missile launchers, known to 
be capable of carrying chemical munitions, hidden in the vicinity of both artillery 
strongpoints. They can emerge from their covered positions, prepare their warheads, and 
fire their missiles within 30 minutes. Past experience has shovm that the FROG crews are 
more stalwart than their artillery comrades — they will continue to prepare and launch 
their missiles even if they are being suppressed by NSFS. Close air support (CAS) 
aircraft with precision guided munitions are the only weapons in the JTF’s possession 
that are highly effective against this target, if the aircraft can arrive in time. 
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At sea, the enemy submarine threat is considerable. The Green forces have one 
Alfa-class submarine known to be in the area, and one more possible. They possess 
MI-24 Hind helicopters and strike aircraft as well, both of which have demonstrated the 
capability to launch anti-ship missiles. 

The only surface threat that friendly naval forces face is that posed by the Green 
navy, which possesses numerous fast patrol boats. These fast patrol boats can either fire 
very potent Russian torpedoes or be loaded with explosives for suicide missions. 

Finally, there are two suspected Silkworm anti-ship missile launchers: one in the 
city of Eastport itself and the other in a southern residential district. These Silkworm 
launchers were placed in residential neighborhoods by the Green forces because they 
knew U.S. planners would be reluctant to target these areas. Accordingly, if the CVBG or 
ARG wish to target a Silkworm launcher, they must first get visual confirmation of its 
presence, using theater SR-71 assets, and any strike must use CAS with precision guided 
munitions in order to minimize collateral damage. 

3. Friendly Situation and Asset Ownership 

The JTF exists within the structure of the Mediterranean Command (MEDCOM). 
There is a theater-level Joint Force Air Component Commander (JFACC) and other 
fiiendly forces operating against the enemy in Orange, but not in concert with the JTF. 
The only aircraft from the CVBG available to support the JTF are one section of FA-18s 
with laser guided bombs to attack FROG launchers, another designated to attack 
confirmed Silkworm missile sites, and enough combat air patrol (CAP) aircraft, used for 
anti-air warfare, to man two CAP stations, one above the CVBG and the other above the 
ARG. All other CVBG assets will support the theater JFACC, and will be unavailable for 
JTF use. The CVBG will control an aircraft carrier, an AEGIS cruiser which is only 
capable of performing anti-air warfare (AAW) functions, and a frigate which can only be 
used for antisubmarine warfare (ASW). The ARG will control two destroyers in position 
to provide NSFS against either artillery strongpoint (incapable of performing ASW or 
AAW), several amphibious ships with the MEUs embarked, and one Stinger platoon 
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detached from one of the MEUs capable of providing close in air defense against 
helicopters (the only asset in the JTF so capable). 

MEU 1 is composed of one Advanced Amphibious Assault Vehicle (AAAV) 
mounted infantry company, one V-22 Osprey mounted helibome infantry company, one 
division (4) of AH-IW Cobra attack helicopters (indivisible), and one V-22 mounted 
engineer platoon. MEU 2 is composed of one AAAV mounted infantry company, one 
V-22 mounted helibome infantry company, and 2 MEDEVAC helicopters (also 
indivisible). MEU 1 has the Cobras and Engineers because it is considered probable that 
the port will be more heavily defended by mechanized assets and minefields than the 
airfield. Each MEU will be considered to have a unmanned aerial vehicle (UAV) flying in 
its support for the duration of the operation. The players will not control the UAVs but 
their presence will be represented by the nearly omniscient battlefield picture each MEU 
will possess. 

The CJTF controls the two sections of CAS aircraft previously mentioned, one 
mine countermeasures (MCM) helicopter embarked aboard the ARG which can clear 
mines if they are detected, a section of SH-60s armed with Penguin missiles aboard the 
carrier to be used against any small patrol boats that threaten JTF forces (anti-surface 
warfare (ASUW)), and a V-22 mounted helibome infantry company aboard the ARG. 
This helibome infantry company is the JTF reserve. In addition, there is a possibility of 
obtaining JFACC air defense assets from Sicily at the CJTF’s request in the event that the 
carrier-based fighters become unavailable, and a SR-71 is constantly in orbit, in general 
support of the theater commander-in-chief, that can be requested by the CJTF for any 
immediate imagery requirements. 

As mentioned previously, the assets were designed unrealistically as 
one-of-a-kind assets, in which only a single asset can accomplish a task in any given 
situation, in order to induce competition where the experimental designers wanted it to 
occur. Additionally, the “non-organic” assets were placed under the CJTF rather than the 
MCC or GCC, although it would have been more realistic, in some circumstances, to 
place the assets at the intermediate level of hierarchy when present. This was done for 
consistency; the experimental designers wanted to hold the resource stmcture constant. A 


56 




summary of the assets available, owners, and the threats that can be destroyed or tasks 
handled by each asset is as shown in Table 3. 


Asset 

Owner 

Task(s) Asset Can Accomplish 

Helibome Infantry Company 

MEUl 

Attack Enemy Positions & Ground 


MEU2 

CJTF 

Forces, Hold Positions 

AAAV-Mounted Infantry Company 

MEU 1 

Attack Enemy Positions & Ground 


MEU2 

Forces, Hold Positions 

Engineer Platoon 

MEU 1 

Clear Mines on Land 

AH-1W Cobra Helicopters 

MEUl 

Enemy Tanks 

MEDEVAC Helicopters 

MEU 2 

Perform Medical Evacuation 

Frigate 

CVBG 

Perform ASW 

AEGIS Cruiser 

CVBG 

Perform AAW 

F-14 CAP 

CVBG 

ARG 

Perform AAW 

Destroyer 

ARG 

Provide NSFS Against Artillery 

Stinger Platoon 

ARG 

Perform AAW Against Helicopters 

SH-60 Helicopters 

CJTF 

Perform ASUW 

CAS Aircraft 

CJTF 

Destroy FROG & Silkworm Launchers 

F-15 CAP 

CJTF 

Perform AAW 

SR-71 

CJTF 

Identify Silkworm Launchers 

MCM Helicopters 

CJTF 

Clear Mines fi-om Beach 


Table 3. Assets, Ownership, and Capabilities 


The DDD-III implemented the asset-to-task matchings via specification of task 
resource requirements and asset resource capability. To each task (and asset) there was 
associated a 7-dimension resource vector R = [rl, r2, ... , r7] with components that 
correspond to combat capability/potential, or task requirements in various categories. For 
example, rl — air combat, r2 — sea combat,..., r5 = mines, r6 = holding/occupying, r7 = 
medivac. By giving a specific task a set of values for R the DDD-III establishes what 
(mix of) assets with their corresponding Rs suffice to correctly process that task. Thus, 
mine-clearing helicopters would have values for r5 corresponding to those required for 
mine clearing tasks, but other assets would have lower values for r5, or zero (Kemple, et 
al., 1996a). 
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4. 


Mission 


Ground Component: To secure the port and airfield of Eastport, to allow for the 
introduction of follow-on forces. 

Maritime Component: To support the amphibious operation with close air 
support, naval surface fire support, mine countermeasures, and air defense assets, and to 
defend the CVBG and ARG from air, surface, and subsurface threats. 

5. Execution 

Each MEU will simultaneously land its AAAV-mounted company on the beach. 
MEU 1 will attack Red Beach, and MEU 2 will attack Blue Beach. MEU 1 will 
simultaneously secure the commanding terrain overlooking Red Beach and the port with 
its helibome company. Once the beaches and commanding terrain are secure, the two 
AAAV-mounted companies will proceed down the roads from their respective beaches, 
clearing minefields with the engineer platoon, killing counterattack forces with the 
Cobras, and conducting MEDEVACs as necessary. 

Each MEU will have a UAV (launched from the ARG) airborne for the duration 
of the operation. The UAVs will keep the artillery strongpoints and the suspected FROG 
sites under constant surveillance, so that NSFS or CAS assets can be brought to bear 
immediately if they are needed. The section of CAS aircraft earmarked for use against 
FROG launchers will be on 5 minute strip alert aboard the aircraft carrier. 

Once the roads have been cleared, the AAAV-mounted companies from MEU 1 
and MEU 2 will attack the port and the airfield, respectively. MEU 2’s AAAV-mounted 
company will be joined in its attack by a helibome company from MEU 2. It is important 
that, once the AAAV-mounted companies land on the beach, the airfield and port be 
taken as quickly as possible, before the enemy has a chance to organize his defense and 
send reinforcements. It is desired that final assaults on the airfield and port be conducted 
simultaneously, in order to present the enemy commander with the most confusing, 
dilemma-filled environment possible, but, if one attack must be conducted before the 
other, the airfield takes priority. If the airfield attack is held up for any reason, the port 
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attack should wait to retain the synergism of concurrent attacks; if the port attack is held 
up, the airfield attack should go forward. The CJTF’s reserve infantry company can be 
requested by whichever MEU needs it at any point during the operation, in case either the 
port or the airfield are too well defended for MEU 1 or MEU 2 to be able to secure them 
with the forces available. 

Due to hydrographic limitations, the ARG and the CVBG will have to be 
significantly separated during the operation, enough to preclude them fi'om being under a 
joint air defense umbrella provided by the AEGIS cruiser. Thus, the AEGIS cruiser will 
remain with the CVBG, but will position itself so that it can rapidly move fi'om the 
CVBG to the ARG if that becomes necessary. Additionally, the two destroyers will be 
inshore, providing NSFS support, while the frigate is the primary anti-submarine warfare 
platform for the CVBG. The frigate performing anti-submarine warfare will, like the 
AEGIS cruiser, position itself so that it can quickly move to support the ARG if that is 
necessary. Any assets supporting the ARG must be under the control of the ARG, and 
assets supporting the CVBG must be under the control of the CVBG. 

The ARG will launch the aforementioned three companies of Marines for the 
initial assault on Red and Blue Beaches. The ARG will launch the mine countermeasures 
helicopters. Cobras, MEDEVAC aircraft, the air assault for MEU 2’s attack on the 
airfield, and the CJTF reserve when called to do so. The ARG will also, with its 
destroyers providing NSFS, suppress the artillery strongpoints ashore when requested to 
do so by either of the MEUs. 

The CVBG will keep two sections of FA-18s with precision guided munitions on 
standby at all times: one to be used against FROGs (in support of the MEUs), and the 
other against Silkworms (in support of the CVBG or ARG). The CJTF will be launch 
authority for both sections. The CVBG will also provide 2 sections per hour of air 
defense aircraft (FA-18 or F-14), with one CAP station over the CVBG and the other over 
the ARG. 

If the CVBG or ARG encounters a surface threat, then it must request the SH-60s 
from the CJTF in order to deal with that threat. If a suspected Silkworm launcher is 
detected, then it must be identified first by the SR-71 before it can be destroyed. A 
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Silkworm launcher detected at the northernmost site threatens the CVBG; at the 
southernmost site, the ARG. 

6. Priorities 

The JTF’s overall priority, and the priority within the ground component, is MEU 
2’s attack on the airfield, because buildup of friendly forces can be most quickly and 
effectively achieved through air transport. 

The following was given to the subjects as the CJTF’s priorities within the 
maritime component: if both the ARG and CVBG are threatened by the enemy, the ARG 
has priority of support against submarine threats, fixed-wing air threats, and patrol boats. 
If there is a threat of an air attack against the ARG, the ARG should get the AEGIS 
cruiser and a CAP. The frigate performing anti-submarine warfare and the AEGIS cruiser 
stay with the CVBG unless a necessity occurs with the ARG, however, because the 
CVBG is considered a more likely target for the enemy. The CVBG has priority against 
land-based Silkworm sites and helicopters. The Stinger platoon will remain on the ARG, 
however, because it is considered a more likely target for enemy helicopters, since the 
only known enemy helicopter bases are closest to the ARG, and will only transfer to the 
CVBG if there is evidence of an imminent attack. To expedite this transfer, should it 
become necessary, the Stinger platoon will have V-22 helicopters at its disposal. 

7. Scenario 13, Competition Over Organic Assets 

In Scenario 13, the ground component (MEU 1 and MEU 2) competed for MEU 
Us engineer platoon and Cobras and MEU 2’s MEDEVAC helicopters. The maritime 
component (ARG and CVBG) competed over the ARG’s Stinger platoon and the 
CVBG’s AEGIS cruiser, frigate, and section of CAP aircraft. Non-organic assets that 
were not competed over, but were used, were the reserve helibome company, mine 
countermeasures helicopter, JFACC CAP aircraft, the SH-60s, the SR-71 mission, and 
the CAS aircraft to be used against Silkworms and FROGs. These non-organic assets 
were competed over in Scenario 24. 
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On the ground side, the scenario started with MEU 2 detecting mines as it 
approached the beach. MEU 2 should have immediately requested the mine 
countermeasures helicopter to clear the mines. Once the mines were clear, the air assault 
on commanding terrain and the AAAV assaults on Red and Blue Beaches then occurred 
conciurently. After the AAAV-mounted companies had taken the beaches and began 
moving down their respective roads, enemy tanks were observed moving down both 
roads towards Red and Blue Beaches. MEU 1 and MEU 2 competed for the Cobras — 
since MEU 2 had priority, the correct response would be for MEU 2 to use them first. 
Parallel with the assault, the enemy artillery from the northern strongpoint was observed 
coming out of its bunkers by MEU 1, which should have called NSFS to suppress it. The 
artillery would emerge from its strongpoints about every five minutes throughout the 
scenario to threaten alternately MEU 1 and MEU 2. This was not used as a competition 
event, but as “busywOrk” to ensure the players had enough to do. 

Soon after the tanks appeared, friendly casualties were incurred at both beaches. 
MEU I’s casualties were most severe, so the correct response was for MEU 2 to give 
their MEDEVAC helicopters to MEU 1. 

After the enemy tanks were dealt with, MEU 1 and MEU 2 could begin moving 
down their respective roads toward their objectives. They then simultaneously 
encoimtered minefields on the roads — MEU 2 had priority, so the correct response was 
for MEU 1 to give its engineer platoon to MEU 2. At about the same time as MEU 1 was 
clearing its mines, a FROG launcher emerged from hiding, observed by MEU 2’s UAV. 
MEU 2 should then have requested the standby CAS section to attack the FROG 
launcher. MEU 2, meanwhile, should have begun conducting its coordinated attack on the 
airfield. 

After MEU 1 finished clearing its mines, it should have attacked the port. As it 
approached the port, the MEU 1 commander realized that the enemy’s strength at the port 
was greater than he expected. Fie needed to call for the reserve company before he could 
attack. Upon completion of MEU I’s attack, the ground objective was achieved. A task 
structure diagram depicting Module 1 is given in Figure 6. 
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On the maritime side, shortly after the detection of the mines in front of Blue 
Beach, submarines were detected, one moving toward the ARG and the other toward the 
CVBG. The correct response was for the CVBG to give its frigate to the ARG. At the 
same time, two sections of CAP aircraft launched from the carrier, one for the CAP 
station above the CVBG, and the other for the CAP station over the ARG. They remained 
on station for one hour. 



62 

























Soon afterward, and after the MEUs’ assault on Red and Blue Beaches, Green 
Hind helicopters with antiship missiles were detected preparing to take off from two 
airfields, one within range of the CVBG and the other within range of the ARG. The 
correct response was for the ARG to transfer its Stinger platoon to the CVBG, since the 
CVBG had priority. After this, and concurrently with the clearing of the minefields in the 
roads ashore, two things happened. First, fast patrol boats were detected approaching the 
CVBG. The CVBG should have requested the SH-60s firom the CJTF to destroy this 
threat. Also, an intelligence report of a fixed-wing air attack preparing to take off against 
the ARG was received from the theater commander-in-chief. The correct response was 
for the CVBG to transfer the AEGIS cruiser to the ARG. Also at the same time, both 
CAP aircraft ran out of fuel, and returned to the carrier. Only one relief section was 
available — belonging to the CVBG. This should also have been diverted to the ARG, 
because the ARG had priority. Soon afterward, if requested, a section of JFACC F-15s 
from Sicily came out to support the CVBG. 

Next, a report was received of a Silkworm site in the north, threatening the 
CVBG. The CVBG requested SR-71 overflight to confirm the missile site, then requested 
launch of the FA-18s with precision guided munitions to destroy it. Figure 7 is a task 
structure diagram depicting the Module 3 task. 

8. Scenario 24, Competition Over Non-Organic Assets 

In this scenario, the organic and non-organic assets were the same as in Scenario 
13; however, the organic assets were not competed over, and the non-organic assets were. 
Scenario 24 unfolded as did Scenario 13, except for the following: 

On the ground side, both MEUs simultaneously detected mines as they 
approached the beach. Since MEU 2’s attack had priority, the correct response was for 
the CJTF to give MEU 2 the mine countermeasures helicopters first. Each assault began 
immediately after the mines were cleared from its respective beach. Once the MEUs 
landed on the beaches, the enemy tank column and mines only appeared on the north 
road, threatening MEU 1. There was no competition for the engineers and Cobras. 
Casualties were only incurred by MEU 2, so there was no competition for the 
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MEDEVAC helicopter. FROG launchers, however, were detected simultaneously by both 
MEU 1 and MEU 2, causing competition over the CAS aircraft. Since MEU 2 had 
priority, the correct response was for MEU 2 to get the CAS aircraft first. Finally, as the 
MEUs approached their objectives, it became clear that neither would be able to take its 
objective without reinforcements, so there was competition over the JTF reserve. The 
correct response was for MEU 2 to get the reserve first, then MEU 1. Figure 8 depicts 
Module 2. 
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On the maritime side, the enemy submarine was detected moving toward the 
CVBG instead of both the CVBG and the ARG, eliminating the competition over the 
frigate. The enemy helicopters detected preparing to take off were only within range of 
the ARG, not the CVBG, eliminating the competition over the Stinger platoon. There 
were reports of two Silkworm sites instead of one, however, one threatening the CVBG 
and the other threatening the ARG. This caused competition over the SR-71 and CAS. 
Here, the SR-71 flyover should have been requested first for the CVBG and then for the 
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ARG. Both sites were confirmed (simultaneously), and the CVBG should have gotten the 
FA-18’s first, and then the ARG. The report of the air attack was only against the CVBG, 
eliminating the competition over the AEGIS cruiser. Also, no CAP aircraft at all were 
available for the second coverage period; the ARG and CVBG then competed over a 
section of CAP aircraft that became available almost immediately from the JFACC. The 
correct response was for the ARG to get the JFACC CAP, because the air attack was over 
and it the ARG had priority. Finally, fast patrol boats were detected moving toward both 
the ARG and CVBG, inducing competition over the SH-60s. The correct response was 
for the CVBG to get the SH-60 assets. Module 4 is depicted in Figure 9. 

9. Development of Training Scenarios 

In order to familiarize the subjects with the general situation in the scenarios, the 
DDD III simulator, the operational context, and activities required such as transferring 
assets back and forth, requesting assets, communicating using preformatted message sets, 
et cetera, I created training scenarios based on the experimental scenarios. The tr aining 
scenarios were identical to the experimental scenarios, except that they did not contain 
any competition events. I developed two training scenario varieints, each composed of a 
ground and a maritime module, and designed them so that each lower level unit had an 
opportunity to perform each subtask and use every asset. For example, if, in one training 
scenario, MEU 1 killed tanks with its Cobra helicopters, then, in the other training 
scenario, MEU 1 transferred the Cobras to MEU 2 to destroy tanks. The specific tr aini ng 
scenarios are described below. 

a. Training Scenario 13 

MEU 2 detected mines as it approached Blue Beach, and had to clear 
them. After the mines had been cleared, MEU 1 and MEU 2 continued their coordinated 
attack on the commanding terrain. Red Beach, and Blue Beach. Once the beaches were 
secure, MEU 2 encountered tanks on the south road, and needed to request MEU I’s 
Cobras. MEU 1 then needed to MEDEVAC casualties, and requested MEU 2’s 
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Figure 9. Module 4: Competition Between Maritime Units for Non-Organic Assets 


MEDEVAC helicopter. Subsequently, MEU 1 encountered mines on the north road, and 
cleared them with their own engineer platoon. 

Meanwhile, MEU 2 detected a FROG launcher, and needed to request 
CAS from the CJTF. After MEU 1 cleared its mines, it continued the attack and realized 
that it needed reinforcements in order to capture the port. MEU 1 then requested the 
reserve from the CJTF. When MEU 2 reached the airfield, it conducted a coordinated 
attack with its AAAV company and its helibome company. 
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Throughout the training scenarios, artillery targets popped up, and either 
MEU 1 or MEU 2 needed to request NSFS from the CJTF in order to suppress the 
targets. 

On the maritime side, the ARG was threatened by a submarine, and 
requested the frigate from the CVBG. Meanwhile, CAPs were launched and maintained 
above the ARG and CVBG. Only the ARG was threatened by a helicopter attack, and 
used its own Stinger platoon to defend itself Then, an inbound air attack was reported, 
but only threatened the CVBG, which defended itself with the AEGIS cruiser and 
requested a section of CAP from the JFACC (via the CJTF), its own CAP having run out 
of fuel by then with no others available. At the same time, patrol boats were observed 
heading toward the CVBG, which requested the SH-60’s from the CJTF in order to 
defend itself Finally, the ARG was threatened by a Silkworm launcher, and needed to 
request the SR-71 imagery and a section of CAS from the CJTF in order to destroy the 
launcher. 


b. Training Scenario 24 

This was identical to Training Scenario 13, but “who needed which asset” 
was reversed. MEU 1 needed the mine countermeasures helicopter and CAS from the 
CJTF, and needed to use its own Cobras, while MEU 2 will needed to request the reserve 
company from the CJTF and the engineer platoon from MEU 1, and used its own 
MEDEVAC helicopters. 

On the maritime side, the CVBG needed to request the SR-71 imagery and 
CAS from the CJTF and the Stinger platoon from the ARG, and used its own 
anti-submarine warfare asset. The ARG had to request the JFACC CAP and the SH-60s 
from the CJTF, and the AEGIS cruiser from the CVBG. 

E. GRADING DIMENSIONS OF TASK STRUCTURE IN SCENARIOS 

The final step in the task design process, after drafting the scenarios that differ in 
the task structure dimension of interest and comply with the desired task structure, is to 
grade the dimensions of task structure in order to ascertain whether they differ and are 
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held constant in the right dimensions. Below Modules 1 and 2 are compared against each 
other, as are Modules 3 and 4. 


1. Modules 1 and 2 

a. Uncertainty 

The main issues of uncertainty that occur in both modules are the location 
of the tanks, the location of the offshore mines and mines on the road, the enemy strength 
at the port and the airfield, which FROG launchers and artillery will pop up and when, 
and the location, timing, and priority of MEDEVACs. These are the same across both 
modules, so uncertainty in Modules 1 and 2 is constant, and graded as Medium. 

b. Time Pressure 

Time pressure varied across subtasks within modules, but was constant 
across the modules, since subtasks carried the same time pressure scores in one module as 
they did in another. This should be classified as Medium overall, for both modules. 

c. Complexity 

Since complexity is not the dimension of interest in this experiment, it is 
not necessary to decompose it into its five characteristics and score each characteristic. 
The attributes, paths, outcomes, interdependence of outcomes, and probability of linkages 
were all basically the same for both modules. This was true because the modules both 
involved the same subtasks and actions — the difference was in which subtasks were 
performed twice. In Module 1, the subtasks which involved competition over organic 
assets were performed twice, while in Module 2, the subtasks which involved 
competition over non-organic assets were performed twice. Those subtasks were quite 
similar in complexity and level of effort, so an overall score for comparison purposes is 
sufficient. Both Modules 1 and 2 are of Medium complexity. 
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d. Coordination Requirements 

Coordination requirements was the task structure dimension of interest for 
this experiment. The grading of each of the types of dependencies present is as follows: 

(1) Shared Resources. As previously discussed, the shared 
resources dependency was varied in Modules 1 and 2. In Module 1, the grade for 
competition over internal shared resources is High, and the grade for competition over 
external shared resources is None. In Module 2, the grade for competition over internal 
shared resources is None, and the grade for competition over external shared resources is 
High. 


(2) Producer/Consumer Relationships. Although there are more 
solid arrows (indicating hard prerequisites) on the Module 1 diagram (Figure 4) than on 
the Module 2 diagram (Figure 6), the number of subtasks that are affected by these solid 
arrows is in both cases seven. This dependency is graded as Medium for both modules. 

(3) Simultaneity Constraints. This dependency is also graded as 
Medium for both modules. Although, in Module 1, the Assault on Blue Beach subtask 
was required to be conducted in concert with the Assault on Red Beach and Air Assault 
on Commanding Terrain subtasks, while only the latter two subtasks were conducted in 
concert in Module 2, the additional coordination required for that parallelism was 
negligible. 


(4) Task/Subtask. The task/subtask dependency is not present in 
either module. The scenarios were given to the players in “prescripted” form, to a large 
degree, and there was no requirement for tasks to be subdivided among actors. 

e. Magnitude 

Magnitude is also constant across tasks. Both Modules 1 and 2 contain 20 
subtasks each, and most of these subtasks are the same in both tasks. The difference, as 
with complexity, is in which subtasks are performed twice. The subtasks performed twice 
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in Module 1, Conduct MEDEVAC, Kill Tanks, and Clear Mines, require a total of 12 
actions per pair of subtasks. The subtasks performed twice in Module 2, Clear Mines 
from Beaches, Kill FROG Launchers, and Reinforce Attacks, also require a total of 12 
actions per pair of subtasks. Thus, the subtasks are equivalent, since they all require the 
same number of actions, so the tasks would each be scored as 20 on a “subtasks” scale. 

f. Resources Required 

Module 1 and Module 2 each require 19 resources to complete all 
subtasks, so resources required is constant across tasks. 

g. Information Required 

Module 1 and Module 2 each require 21 separate pieces of information to 
complete all subtasks, so information required is also constant across both tasks. 

h. Task Formalization 

Both Module 1 and Module 2 are High formalization. The subtasks that 
must be completed for both tasks are well defined and well structured, and there are clear 
paths to the correct solution. 

L Dynamicity 

Dynamicity is High for both tasks. Almost all subtasks within both 
modules would change over time. 

2. Modules 3 and 4 

a. Uncertainty 

Uncertainty in Modules 3 and 4 is Medium, as in Modules 1 and 2. The 
uncertainty issues that occur in Modules 3 and 4 are the number and target of attacking 
submarines, the number and target of fixed wing and rotary wing air attacks, the number 
and location of Silkworm launchers, and the number and target of attacking patrol boats. 
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b. Time Pressure 

The time pressure characteristics were the same for Modules 3 and 4 as 
they were for Modules 1 and 2, and is graded as Medium for both modules. 

c. Complexity 

Complexity circumstances were the same for these modules as they were 
for Modules 1 and 2. Complexity is graded as Medium for Modules 3 and 4 as well. 

d. Coordination Requirements 

(1) Shared Resources. This is the same as it was for Modules 1 
and 2. In Module 3, the grade for competition over internal shared resources is High, and 
the grade for competition over external shared resources is None. In Module 4, the grade 
for competition over internal shared resources is None, and the grade for competition 
over external shared resources is High. 

(2) Producer/Consumer Relationships. There are six solid arrows 
in both the Module 3 and Module 4 diagrams, indicating 6 producer/consumer 
relationships between subtasks within each task. This dependency is graded as Medium 
for both modules. 


(3) Simultaneity Constraints. This dependency is also graded as 
Medium for both modules. There are a total of three solid bars indicating parallel 
activities in each of the two modules. 

(4) Task/Subtask. As was true in Modules 1 and 2, the 
task/subtask dependency is not present in either of these two modules. 

e. Magnitude 

Magnitude is again considered constant over both Modules 3 and 4, 
although Module 3 has 21 subtasks and Module 4 has 22. The difference occurred 
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because two of the competition events in Module 4, Identifying and Striking Silkworm 
Sites, required the subtasks to be performed twice, while all the other competition events 
in these two modules were only performed once. However, the first subtask in a two 
competitive subtask chain, such as the two “Strike Silkworm Site” subtasks in Module 4 
and all the competitive subtasks in Modules 1 and 2, requires twice as many actions as 
the second subtask in the chain, because the first subtask is where the recognition and 
resolution of the competition actually occurs. The second subtask in the chain, 
performing the lower-priority subtask, is merely a “push-button” subtask, requiring little 
decisionmaking skill. Thus, adding an extra subtask in Module 4 was considered of 
relatively little significance. 

/. Resources Required 

Module 3 and Module 4 each require 20 resources to complete all 
subtasks, so resources required is constant across tasks. 

g. Information Required 

Module 3 and Module 4 each require 24 separate pieces of information to 
complete all subtasks, so information required is also constant across both tasks. 

h. Task Formalization 

Modules 3 and 4 contain the same characteristics as Modules 1 and 2, and 
are also graded as High formalization. 

L Dynamicity 

Dynamicity is again High for both tasks. Almost all subtasks within both 
modules would change over time. 
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F. CONDUCT OF EXPERIMENT 


1. Experiment Setup 

a. Physical 

The six test subjects for each team were presented the scenario on a 
distributed, interactive, computer simulation running on seven SUN SPARC™ 
workstations. (The seventh station was the experimenter’s station.) The facility used was 
the Systems Technology Laboratory at the Naval Postgraduate School in Monterey, CA. 
Although all subjects were in the same room, dividers were placed between them, and (to 
facilitate subsequent data analysis) communications among subjects was restricted to 
preformatted computer messages built into the simulator. 

b. Lead Team 

A group of eight NPS officer students from the Joint C4I Systems, Space 
Systems Operations, and Operations Research curricula were designated as the “lead 
team” for this experiment. Three of the members of the lead team were so designated 
because their theses involved the experiment; the other five were enrolled in CC4103, 
“Evaluation of Command and Control Systems,” a required course in the Joint C4I 
Systems curriculum, of which the conduct of this experiment was an integral part. The 
lead team was composed of officers from all four branches of the armed forces, and all 
members had recent operational experience. The author headed the lead team. 

The lead team performed such tasks as preparation of training materials 
for the subjects, conduct of subject training, setup of the physical space, debugging the 
simulator and the scenario’s implementation in the simulator, conduct of the experimental 
runs, and data collection. The lead team also provided invaluable suggestions and advice 
concerning all of the above subjects as well as scenario development, and filled many 
gaps in the author’s experience. 
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c. 


Test Subjects Used 


The test subjects were 24 military officer students from the Joint C4I 
Systems curriculum at NFS. The subjects were organized into four six-person teams. The 
teams were formed by the experimenters with participants distributed according to 
military occupational/warfighting specialty and branch of service, to the extent that that 
was possible given the demographics of the sample. 

Since there was a fairly significant difference between the operational 
experience of the subjects, the experimenters were concerned that some subjects would be 
more familiar than others with the appropriate tactics to employ in a given situation, and 
that this might have an undesirable effect on the performance measures chosen as 
dependent variables. In order to counter such an impact, the scenarios and the operations 
order were tailored to facilitate a “cookbook” approach to each situation. This approach 
further aided the experimenters’ attempt to steer the subjects toward the competition 
events that were of prirhary interest in the experiment. 

d. Simulator 

The experiment was conducted using the Distributed Dynamic 
Decisionmaking-III (DDD-III) simulator. Earlier variants of the DDD had been used 
extensively in the past to study decisionmaking in the Navy’s Composite Warfare 
Commander (CWC) organizational structure. In a concomitant effort, the DDD was 
extended to fit the general requirements of tier-I experimentation for the A2C2 project, 
and was adapted to meet the specific requirements of the current experiment. Although it 
is not a tactical model on the level of RES A, JTLS, MTWS, CBS, or AWSIM, it contains 
data collection and variable manipulation capabilities that make it very appropriate for a 
research environment. For a more detailed treatment of DDD-III, its characteristics, and 
implementation in DDD-III of the scenarios and organizational structures used in this 
experiment, see Higgins (1996). 
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e. Matching of Subjects to Task/Organization Structure 

The experimental team decided to keep the subjects in the same position in 
the organization structure through all of the training and data runs; if a subject began the 
training runs as the CJTF for his team, for example, he would remain CJTF throughout 
the experiment. The only position for which this was not possible was the GCC/MCC 
position. Since half the experimental and training runs used a GCC, and the other half 
used an MCC, the individual who played this position would switch back and forth 
accordingly. This caused problems, as will be discussed in the lessons learned section of 
this chapter. 

To the greatest degree possible, the experimenters and lead team attempted 
to match the subjects to positions in the organizational structure for which they had some 
operational experience. For instance, the MEUs were played by Marine and Army 
officers, and the CVBG and ARG were played by Navy pilots and surface warfare 
officers. Unfortunately, our sample was heavy in Navy officers, which meant that all of 
the MCC/GCC players were naval officers. This was not an issue when the intermediate 
level of hierarchy was an MCC, but caused difficulty when the intermediate level was a 
GCC. This will also be discussed in the lessons learned section. 

2. Operationalization of Task/Organization Structures 

The organization structures shown in Figure 4 and the task structures shown in 
Figures 6 through 9 were operationalized in three significant respects: through asset 
structure, communications structure, and information structure. 

a. Asset Structure 

The scenarios were designed so that if a unit must perform a specific task, 
then the assets required should be transferred to that unit, rather than the original owner 
attempting to perform the task for the unit that required the asset. For example, if MEU 2 
was under attack by a tank colunrn, the experimenters wanted MEU 1 to transfer the 
necessary asset (the Cobra helicopters) to MEU 2 to destroy the tanks, rather than MEU 1 


76 




destroy the tanks itself. This was done to ensure that the proper competition events 
actually occurred, and led to the issue of transferability. 

All assets in the scenario were transferable, with few exceptions. The 
nontransferable assets included such assets as the amphibious shipping and the aircraft 
carrier, which were not directly needed to accomplish competitive tasks. All assets shown 
on Table 3 were transferable by their owners. 

If the asset owner chose not to transfer an asset as requested by a unit 
needing it, a higher-level decisionmaker could force transfer of the asset(s). For example, 
if the ARG requested an asset from the CVBG, and the CVBG ignored the request, the 
MCC (if present) or CJTF could forcibly transfer the asset from the CVBG to the ARG, if 
he determined that the ARG’s need for the asset outweighed that of the CVBG. 

While all organic assets were owned by the lower level units (the MEUs, 
the ARG, or the CVBG), all non-organic assets were ovmed by the CJTF. No assets 
began the scenario under the ownership of the GCC or MCC. This was contrary to logic, 
because some non-organic assets were component specific, and should have naturally 
been under the control of the GCC or MCC, if present. An example is the SH-60 ASUW 
helicopters — if the MCC was present, he should have controlled the asset, because there 
is no conceivable use to which the ground component could have put the asset. If the 
MCC was not present in the structure, though, the asset would have been under the 
control of the CJTF. It was for this reason that all non-organic assets were kept under the 
control of the CJTF — the experimenters did not want the assets shifting back and forth 
between the CJTF and intermediate commanders for the different organization structures, 
but wanted to keep the asset structure constant. 

b. Communications Structure 

Communications in this experiment were limited to preformatted 
messages using the DDD-III simulator. No verbal communications were allowed. 

Copies of all messages sent by a decisionmaker were automatically 
forwarded to the next higher level in the hierarchy. If a lower-level unit, such as MEU 1, 
communicated with another low-level unit, such as MEU 2, a copy of the message was 
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sent to the intermediate commander. In this case, that is the GCC (if present) or the CJTF. 
And, if the intermediate level commander communicated with a lower level unit, a copy 
of his message was forwarded to the CJTF. 

When an intermediate level commander was present, the low-level units 
could not communicate directly with the CJTF. In such cases communications followed 
the chain of command via the MCC or GCC, as the case may be. 

c. Information Structure 

One of the major assumptions behind the “flattening” concept discussed 
earlier is the existence of a common operational picture (COP). All commanders at all 
levels must have a common view of the battlespace they must see the same threats, at the 
same time. Since our purpose was to test organizational structures in a future environment 
of shared, global information, the COP was one of the givens of our experiment. When 
one decisionmaker in the organization saw a threat or task, it was seen by all others at the 
same time. It was felt that this common view might reduce parochialism in certain 
circumstances, through fostering of shared mental models among team members. 

3. Training 

The experimental team felt that the proper training of the subjects in the operation 
of the simulator and the requirements of the operations order (OPORDER) was vital to 
the success of the data runs. Two aspects of this training were significant: the tr aini ng 
materials that the lead team and experimental team generated, and the conduct of the 
training itself 


a. Training Materials 

The lead team and experimental team developed three primary training 
aids for the training portion of the experiment: an OPORDER which transformed the 
scenarios developed by the lead team into a directive for execution of an operation, a 
tutorial designed to aid the subjects in using the DDD-III to implement the OPORDER, 
and the scenarios developed for the training portion of the experiment. 
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(1) Operations Order. When a military operation or exercise is 
conducted, an OPORDER is given as an implementation directive. This OPORDER tells 
the unit(s) that will conduct the operation or exercise the general situation, enemy forces, 
friendly forces available, the mission, how the mission will be executed, and logistics and 
command and control information. Since this was the language that the subjects spoke, 
the experiment team determined that the information that the subjects needed to execute 
the scenario should be given in that format. 

(2) Tutorial. The tutorial was the link between the OPORDER and 
the DDD-III. It described the simulator to the subjects and its display and user interface, 
functions of the mouse, requesting, launching, moving and transferring assets, identifying 
and attacking threats, and use of communications messages. The tutorial also listed and 
described in detail all the objects that appear on the DDD-III screen, including friendly 
and enemy assets and terrain features, and gave a detailed description of the organization 
structures used in the experiment and how they are implemented in DDD-III. Finally, the 
tutorial included a single-page “cheat sheet” for use as a quick reference that concisely 
described all the objects on the screen and assets that must be used to destroy enemy 
threats, abbreviations used by DDD, and a list of assets, the platforms on which they are 
carried, and how each asset is used. 

(3) Training Scenarios. The training scenarios, described in 
Section D of this chapter, were devised to help the subjects learn about the simulator and 
OPORDER, and allow them to become proficient in the skills that would enable them to 
compete over assets and successfully resolve the competition. The experimenters did not, 
however, want to “spoil” the competition events that would occur in the data runs, so the 
training scenarios had to be devised with care to not include competition events. These 
scenarios were written by the author, with advice and assistance from the lead and 
experimental teams. Refer to Section D for details of the scenarios that were developed. 
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b. Conduct of Training 

Initially, the subjects were given a one-hour brief in a classroom on the 
fact that they were taking part in an experiment (no experimental objectives were 
included), the OPORDER, the organization structures they would be using, and the 
DDD-III. The purpose of this brief was only to give the subjects a general overview of 
what they would be doing during the training and experiment runs, and to give them 
some context for the training runs. The training runs were then conducted as previously 
mentioned, using the training scenarios which contained no competition events, but in 
aggregate, had a requirement for all of the subjects to use all the assets within each 
component. During the training runs, four members of the lead team were present to 
assist each team of subjects in familiarizing themselves with the simulator and 
OPORDER. 

4. Experiment Conduct 

The experiment took place during the weeks of 4-8 March and 11-15 March 1996. 
Two of the four teams were run through the experiment each week. Each team completed 
four training runs, followed by four trials during which data was collected (one for each 
task/organization stmcture combination), in a total of four two-hour sessions per team. 
The training runs and the data collection runs were each 40 minutes long, interrupted 
twice for situational awareness probes. In order to compensate for any learning effects, 
the data collection trials were counterbalanced so that each team encountered the four 
conditions in a different order, and each condition appeared in each place in the order 
exactly once, as shown in Figure 10. At least three members of the lead team were 
present at all times during the data collection runs, to monitor the subjects and collect 
data. 
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Group A 

Group B 

Group C 

Group D 

Session 1 

13MCC 

24GCC 

13GCC 

24MCC 

Session 2 

24GCC 

13MCC 

24MCC 

13GCC 

Session 3 

13GCC 

24MCC 

13MCC 

24GCC 

Session 4 

24MCC 

13GCC 

24GCC 

13MCC 


Figure 10. Counterbalancing of Trials for First A2C2 Experiment 


G. SUMMARY 

The task design process described in Chapter III was implemented in this chapter 
to solve the task/scenario design problem for the initial A2C2 experiment. First, the 
experimental designers determined the task structure dimension of interest and desired 
structural characteristics of the task from previous research. Next, I iteratively developed 
scenarios using the task structure description paradigm generated in Chapter III that 
complied with the experimental designers’ requirements. This was done within the 
constraints of the dimensions of task structure defined in Chapter II. Then, I graded the 
completed scenarios based on the grading scheme delineated in Chapters II and III, to 
ensure that the experimental objectives had been met. Finally, I described the experiment 
that was conducted using the scenario developed in this chapter, including further 
discussion of the operationalization of the scenarios and organization structures. 

Chapter V will include a discussion of the lessons learned from the experiment 
with regard to scenario design, and from the above implementation of the scenario design 
process. It will conclude with a summary of the issues discussed in this thesis. 
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V. LESSONS LEARNED AND SUMMARY 


Upon completion of the experiment, based on the observations of the 
experimenters and the lead team, it was clear that there were some ways in which the 
experiment and the task design process discussed in this thesis could have been better 
implemented. I will focus here only on the items that are of specific interest to the 
task/organization structure and scenario development process. 

Following discussion of lessons learned, I will provide a brief summary of the 

thesis. 


A. LESSONS LEARNED FROM SCENARIO DEVELOPMENT PROCESS 
1. Tradeoff Between Realism and Competition 

a. One-of-a-Kind Assets 

Several complaints were received from our more operationally astute 
subjects concerning the scenario’s lack of realism. This was a difficult issue, and the 
experimenters struggled with it during scenario design. If the specific competition events 
of interest were to be induced in a consistent, repeatable manner, the scenario would have 
to force the use of one asset to perform a certain task. This is inherently unrealistic, since 
joint task forces commonly have several, or even many, different assets that could 
perform a given task. However, had we designed the scenario to more accurately reflect 
the real world, then the teams could have in essence created their own task structures, and 
avoided entirely the competition events that were the focus of the experiment. In 
retrospect, it would have been useful to make the competition involve a combination of 
assets, rather than a single asset. The tradeoff, though, is that that would have made 
scenario development much more complex, and would have increased the probability that 
operational background and “weaponeering” skill would have an undesirable effect on the 
variables of interest. 
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b. Hard Prerequisites 

Designing the implementation of the scenario in the simulator so that 
certain activities must be performed before others can (hard prerequisites) is helpful for 
ensuring that a team follows a desired task structure. However, like the design of 
one-of-a-kind assets, development of hard prerequisites carries a price in terms of 
realism, and the value of strictly following a desired task structure must be weighed 
against the value of allowing a team to make mistakes or solve problems in its own way, 
and studying the team’s mistakes or alternate paths. 

2. Requirement of Modules to Describe Similar Missions 

As discussed in Chapter IV, each scenario was developed in two parts, a ground 
module and maritime module. It was desired that the tasks described in these modules be 
identical in dimensions of task structure and physical structure of the task within 
scenarios, because of the experimenters’ desire to separate the modules for analysis 
purposes in order to double the number of data points — thus. Modules 1 and 3 would 
have to be identical, and Modules 2 and 4 would have to be identical. However, the 
nature of the missions of the groimd component (amphibious assault — offensive in 
nature) and maritime component (support the amphibious assault — defensive and 
logistic in nature) were quite different. Although the dimensions of task structure and the 
task structure diagrams for each module were identical or nearly so within scenarios, this 
fundamental difference in the missions required a far different mindset on the part of the 
players for the conduct of each task, and negatively affected the experimenters’ ability to 
consider modules identical within scenarios. It is my belief that, because of the difference 
in nature of air, land, and sea combat, and the parts each play in joint operations, this 
problem is not surmountable within the bounds of operational realism. Therefore, I 
believe that the modular approach to scenario development should either be abandoned or 
that component (land, sea, or air) be analyzed as a factor along with task and/or 
organization structure. Additionally, a further dimension of task structure could be added 
to the current list of nine: Nature of Mission or Nature of Task. 
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3. Span of Control Not Taxed 

There were not enough lower level units in the organization structures used for the 
CJTF to require an intermediate level commander. Since four people is not too many for 
an individual to supervise — his span of control was not taxed — he received no real 
benefit from the presence of an intermediate level of hierarchy. In fact, because the asset 
structure discussed above required that all non-organic assets be retained at the CJTF 
level rather than delegated to the intermediate commander (when present) to do with as 
he saw fit, the intermediate commander constituted a significant roadblock to mission 
performance when the JTF was competing over non-organic assets. Possible solutions 
would include increasing the number of lower level units in each component or 
increasing the number of components. The added units could come from either increasing 
the pool of subjects, requiring members of the lead team to function as confederates, or 
implementing additional units in software. 

4. Additional Dimensions of Task Structure 

Based on lessons learned from the first A2C2 experiment, there are two additional 
dimensions, abstraction perspective and task significance, that an extension of the 
definitions of dimensions of task structure could incorporate for future experiments. 

a. Abstraction Perspective 

Abstraction perspective refers to the context from which an activity is 
viewed. When a task is viewed from the highest level in an organization structure, the 
task may involve a different set of cognitive skills and activities than when it is viewed 
fi’om the lowest level in an organization structure. For example, an amphibious assault, 
when viewed fi-om the highest level in the hierarchy, involves such activities as planning, 
subtask decomposition and assignment, and resource allocation. When viewed from the 
lowest levels in the hierarchy, the task involves performing assigned subtasks, keeping 
superiors informed, requesting further orders/interpretations, et cetera. Representation in 
the task structure diagram of the perspective from which a task or subtask is viewed and 


85 




the activities that must be performed from that perspective would improve the 
development of task structures in future experiments. (Kemple, et al., 1996b) 

b. Task Significance 

Task significance was defined by Davis et al. (1991) as the value of the 
task output to the organization performing the task, and the interdependency between task 
outputs and other operations of the organization. I purposely left this out of the 
dimensions defined in Chapter II. However, it can be argued with some validity that the 
Modules 2 and 4 tasks (the maritime tasks) described in Chapter IV are less significant 
than the Modules 1 and 3 tasks (the ground tasks), since the ground objectives have 
priority, and this difference in task significance could confound analysis. Task 
significance should be accounted and controlled for in future experiments in order to 
address this issue. It would probably be best included in a Nature of Task dimension 
discussed in subsection 2 above. 

B. LESSONS LEARNED FROM CONDUCT OF THE EXPERIMENT 

1. MCC/GCC Player Should Not Alternate 

The manner in which two organization structures were implemented, with the 
middle level of hierarchy alternating between GCC and MCC, was the source of some 
difficulty. First, the fact that one subject alternated between two positions, while all of the 
other subjects stayed in the same position throughout the experiment, meant that the 
GCC/MCC subject knew each of his positions less well than his teammates knew theirs. 
Second, in an actual JTF, the GCC or MCC could reasonably be expected to be a subject 
matter expert, and would probably be the senior ground or maritime officer in the JTF. 
That was not the case in this experiment. Since the same subject was both GCC and 
MCC, he had to be either a Navy officer or a ground officer. Because of the demographic 
makeup of the subject pool, the experimental team was forced to use exclusively Navy 
officers for the GCC/MCC position. While these officers had considerable expertise in 
maritime affairs, they were less expert on ground affairs than their subordinate MEU 
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since the decisions that these Navy officers could be expected to make while MCC would 
be based on a strong operational background, while those made while in the GCC position 
would not. A potentially alleviating solution would be to use different officers for the two 
positions, with a Navy officer as MCC and a ground officer as GCC. 

Another option could be to change the organizational structures to: (1) CJTF with 
only lower level units and (2) CJTF with the same number of lower level units, but a 
component commander supervising each component. Although there are fewer subjects in 
the first structure than the second, that drawback could be outweighed by the ability to 
more clearly see the results of the flattened versus the hierarchical organizational structure 
through more general, whole-force performance measures, rather than measures directed 
specifically at one component. It would also allow for the GCC to only perform as the 
GCC, and the MCC as the MCC, and for each to be from a service which specializes in 
that type of action, and would better manipulate the CJTF’s span of control. 

2. Increase Time Pressure 

Additional time pressure would have improved the experiment. Two of the four 
teams operated under a reasonable amount of time pressure. The other two teams were 
composed of more operationally proficient members, and worked under relatively low 
time pressure. These two more operationally proficient teams tended to “max out” 
performance measures, making it difficult to find any difference between factor levels. A 
solution would have been to increase time pressure by increasing the simulator speed or 
increase the number of activities within each module. 

3. Increased Number of Competition Events 

Each scenario module contained 3 or 4 competition events. It would have been 
useful to increase that to 5 or 6, or even more, to increase the number of data points. 

4. Team Formation 

One difficulty encountered during the conduct of the experiment was the disparate 
levels of experience among the subjects. Those officers with significant operational 
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4. 


Team Formation 


One difficulty encountered during the conduct of the experiment was the disparate 
levels of experience among the subjects. Those officers with significant operational 
experience and the “operational mindset” much more easily adapted themselves to the 
scenario than those without that experience or mindset, and tended to perform better. This 
extreme performance variability made it difficult to craft tasks that maintain a reasonably 
constant level of difficulty across teams and individuals. Possible solutions would be (1) 
make the scenarios less realistic and less operationally relevant, and more oriented toward 
abstracted decisionmaking, somewhat leveling the playing field, (2) additional training of 
teams, (3) exclusion of subjects without some relevant operational experience, or (4) 
finding some way to include the specialties of the non-operationally oriented in the 
scenarios. Of the solutions, (1) is not practical or desired. The direction of these A2C2 
experiments should and will go toward more realism, not less, although at a higher level, 
as the experimenters attempt to gain insight into A2C2 in a joint operational-level context 
with more senior players. Solution (4) would be difficult, because of the variety of 
experiences of the non-operationally oriented. The lack of operational orientation was 
only a problem, in this case, with the Navy OCS officers. The Navy and Air Force do not 
have a real operational training baseline for many of their officers who do not attend a 
service academy or ROTC. If these officers are not in an operational specialty, then they- 
tend to have little or no exposure to operational issues. This is not the case with Marine 
or, to a lesser extent. Army officers, who receive a common operational training baseline 
at various service schools. Implementing solution (4) in this case would have required 
that a job be found for a legal officer, an instructor at Nuclear Power School, and a 
communications officer, all with little or no knowledge of how the Navy fights, and this 
would have been very difficult to do. Solution (2) would also be difficult, because the 
amount of training required to bring a non-operationally experienced officer to the level 
of one Nvith operational experience is not trivial. Solution (3), exclusion fi-om the sample 
of Navy and Air Force officers without either operational experience or who had not 
attended a service academy or ROTC, is probably the most practical. 
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Officers who were operationally experienced, but played a role in the experiment 
outside of their area of expertise did not tend to function as well as their subordinates who 
were in their area of expertise. This was most specifically a problem, as was mentioned 
earlier, in the MCC/GCC realm. The fact that all the MCC/GCC players were Navy 
officers made judging the effect of the extra level of hierarchy more difficult, because the 
organizations tended to perform better when the middle level of hierarchy was on the 
maritime side, as would be expected when Navy officers were playing that role. The 
designers of future A2C2 experiments must ensure that great care is taken to match 
operational experience to the position played in the organizational structure, since those 
future experiments will likely see di greater level of operational fidelity, not less. 

5. Training and Planning 

Some of the teams of subjects, particularly those with greater operational 
experience, approached the experiment as an exercise, in which they wanted to optimize 
their performance. These teams conducted their own “team” training prior to the data 
runs; they went over the OPORDER together, discussed its interpretation and 
implications, and formulated a plan within the plan that was provided to them in the 
scenario. Other teams did not do this, but approached the experiment in more of a 
“cookbook” fashion, in which the teams took the plan that was given them and executed 
it based on the training conducted by the lead team, doing no further coordination, 
planning, or training on their own. The scenario was designed assuming the subjects 
would take the second approach. It was thought that, if the subjects did much of the 
planning on their own, they would create their own task structures rather than follow the 
task structures that produced the competition events that the experimenters were 
interested in. However, this approach runs counter to realistic operational team 
performance, and to the aims of the overall A2C2 project. 

The planning process would be a very likely time within the span of an operation 
for adaptation of organizational architectures to take place, because of the relative leisure, 
thoughtfulness, and potential for putting minds together to solve a problem in the 
planning environment, compared to the more hectic “crisis management” atmosphere that 
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prevails once the execution phase has begun. Additionally, commanders would probably 
be more willing to adapt the structure of their organization during the planning phase than 
they would during the execution phase. Alternatively, a planning phase (for the next 
portion of the operation) and the execution phase (for the current portion of the operation) 
could happen concurrently, or need to happen concurrently, which in and of itself could 
drive adaptation, in order to facilitate conduct of both phases simultaneously. For these 
reasons, not only should a planning phase be included in any future experiments and 
scenario (or concurrent planning and execution phases), but that phase should be a major 
focus of study. 

C. SUMMARY OF THESIS 

This thesis was conducted as a part of the Adaptive Architectures for Command 
and Control (A2C2) project, which seeks to explore adaptation in command and control 
structures. The project’s first experiment involves studying interaction between task 
structure and organization structure. This thesis described a process for developing 
military operational scenarios within a task structure context. First, I conducted a 
literature review, defined the dimensions of task structure applicable to this project, 
developed a grading scale for each dimension, gave examples of the dimensions and 
graded each example, and described how changes in one dimension might affect other 
dimensions. Then a method for developing scenarios in accordance with a predetermined 
structure and visualization of tasks was described, including a task structure diagram and 
a description of a task design process using the diagram and the dimensions previously 
delineated. I then applied the task design process by developing two scenarios for the first 
A2C2 experiment that differed across one of the dimensions of task structure, 
coordination requirements. Finally, I gave a description of the experiment, including 
discussion of operationalization of the scenarios and organization structures, and lessons 
learned from the experiment and application of the task design process with regard to 
scenario design. 
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